Pegasus Mail & Mercury

PayPal is encouraging ISPs to support digital signing, and dropping emails that claim to come from PayPal but do not have the proper digital signature. This is an attempt to combat phishing, which hurts both people and PayPal financially. Digital signing helps prevent it by protecting "@paypal.com" from reaching a customer if it is not signed by PayPal (if the ISP agrees to drop unsigned emails from "@paypal.com"), and by giving customers with clients that support digital signatures a visual cue that the email is properly signed.

In the first few months, fifty million fake emails were prevented from reaching consumers. Is it bulletproof? No. People who do not check digital signatures will still be vulnerable. It is, however, very effective.

I therefore ask that future versions of Pmail and Mercury support digital signatures.

Here is PayPal's paper about the subject: 

http://www.thepaypalblog.com/weblog/files/a_practical_approach_to_managing_phishing_april_2008.pdf

Thx. Impersonations fool many.

---

Kind regards / Peter

CobraA1:

In the first few months, fifty million fake emails were prevented from reaching consumers. Is it bulletproof? No. People who do not check digital signatures will still be vulnerable. It is, however, very effective.

I therefore ask that future versions of Pmail and Mercury support digital signatures.

 

FWIW, Mercury's Content Control can be used very effectively to combat phishing mails as long as one knows what domain(s) the sender's SMTP use(s). For PayPal, such rule would look like:

#
# PayPal
#
IF SENDER CONTAINS "@paypal" WEIGHT 100
OR SENDER CONTAINS "@intl.paypal"
ANDNOT HEADER "Received" MATCHES "*.paypal.com *"
IF SENDER CONTAINS "@paypal." WEIGHT -100
OR SENDER CONTAINS "@intl.paypal"
AND HEADER "Received" MATCHES "*.paypal.com *"

To explain, the first rule triggers if the sender claims to be @paypal, but a received-by header is not .paypal.com (which is the case even if the mail comes from PayPal because of the local received-by header). The second rule looks for a received-by header with the correct domain and gives minus points, thus negates the rule which triggered first. The phisher's mail will most likely not have the correct received-by header. As each CC rule hits only once it works well. This is a example of a recent phishing mail and the result which the above rule produced:

Return-path: <service@paypal.com>
From: "PayPal 2008" <service@paypal.com>
Subject: Unusual activity in your account!

X-UC-Weight: [# ] 100
X-CC-Diagnostic: Sender contains "@paypal" (100)

I'm using this principle since a long time, also to combat ebay/banking/amazon etc. phishing.

Best regards,

Nico

Just wanted to show my content control rules.  Basically the same idea as Nico's but goes one step further.  They haven't missed one yet.  Is it foolproof, no but until they start faking the headers with the proper ip addresses I think it will work fine. 

 

if sender contains "paypal.com" weight 51
if header "received" matches "*paypal.com (64.4.*" weight -1999 tag "real paypal"
if header "received" matches "*paypal.com (66.211.*" weight -1999 tag "real paypal"
if header "received" matches "*paypal.com (206.165.* b*" weight -1999 tag "real paypal"
if header "received" matches "*paypal.com (216.113.* b*" weight -1999 tag "real paypal"

 

and actually until I started using spamwall my rules used to look like this which i think were foolproof.  

if header "received" matches "*paypal.com (64.4.*mercurymailsystem.ca*" weight -1999 tag "real paypal"

for some reason spamwall wraps lines
T his is an actual header from one it caught.  Before spamwall the first two lines appeared as a single line.

Received: from bellerophon.decipherinc.com (204.13.11.51) by
 mercurymailsystem.ca (Mercury/32 v4.52) with ESMTP ID MG00072C (Using
 SSL/TLS, 3DES, CBC mode, keysize 192 bits) ; 24 Mar 2008 15:58:05 -0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com;
 s=decipher; h=From:Date:Message-Id:Subject:To: MIME-Version:Content-Type;
 bh=PBCnalV7W0MIzn04BCgP1bi0cZE2OH/hfZ pLGZ3Cv/4=;
 b=aVgSDI0kAwufXJRAWsLG30Ii2PGClHRRGwX95IJ8+kyL5PuP/Q
 Ixf5Jc+CeaHLD7r1C5TmeWEPTvIfb4A1yvMztL8l/pVAgZrylHzD0nw4VkZf/V+Z
 9y0iAqz2RTafib
DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=decipher; d=paypal.com;
 h=From:Date:X-Complaints-To:Message-Id:Subject:To:Precedence:MIME-Version:Content-Type;
 b=SE6GF1DdwEfuEzGmjJyTnWrqywPDE4Jx+4fk8tUGCp+yPAfE0lGsrQ/82WMnpc4Q68kS6qF3b/+nHD5W4qWU+2Ty77GJuQ+ptZbPygD53MWE93c1lp8lV/WWowuvxMsf;
From: PayPal <survey@paypal.com>
 

 

Forgot to mention that I also do this with the 5 big banks here in Canada and again, I've never had one get through.   Spamwall also catches most of them, but every so often they change the wording in the phishing emails and one gets through but content control catches it and I send it back for training.  If my content control didn't catch it, it would have gone to one of my end users, which is a good reason for not relying on simply one method to catch spam.

 

Jim 

I think it's worth mentioning that Mercury doesn't include the reverse-DNS of the connecting host in the Received: lines it generates, only the client greeting.  That's often forged, so depending upon it is inadvisable, although it might work (as might just checking for the presence or absence of DKIM-Signature: lines on mails you know ought to have them).

 

Cheers,

Sabahattin

 

FWIW, Mercury's Content Control can be used very effectively to combat phishing mails as long as one knows what domain(s) the sender's SMTP use(s).

That's the idea of SPF, actually, which Hotmail and Gmail have adopted. Except that in the case of SPF, the process can be automated instead of manually entering new filters. If you're handling a large number of users, then they could be sending and receiving to and from a large number of domains, and creating manual entries may be tedious, as well as prone to mistakes. You'd have to look up each domain name individually and find all of the mail servers before creating the filters.

(as might just checking for the presence or absence of DKIM-Signature: lines on mails you know ought to have them)

You can do that, although checking the signature itself would make it much more resiliant to spoofing than simply checking for its presence.

I really wish David would adopt SPF - I understand that it does break domain forwarding, but it would be nice to be able to use it for at least important domains such as paypal and local banks, etc... where it really is critical.  I have had accountants ask me if a phishing email was real.  That's scary stuff.  We need all the tools we can get to fight this stuff. 

> I really wish David would adopt SPF - I understand that it does break domain forwarding, but it would be nice to be able to use it for at
> least important domains such as paypal and local banks, etc... where it really is critical.  I have had accountants ask me if a phishing
> email was real.  That's scary stuff.  We need all the tools we can get to fight this stuff.

Are you saying that you would not worry about sites using SPF? Based on what I have read there are as almost as many spammer and phishing sites that have adopted SPF as good site.

---

Thomas R. Stephenson
San Jose, California
Member of Pegasus Mail Support Team

I do not answer private messages from the forum. If you want to contact me use email to techsupp@tstephenson.com.

No I wouldn't be concerned about spammers using SPF at all, not one little bit - my plan is to simply use it to verify important sites like paypal and the major Banks, we only have 5 in Canada.  I'm actually pretty good at catching these now, but think SPF would make it foolproof.   I actually use mercury now to forward mail to our exchange server and understand that if I implemented it on our exchange server than I wouldn't be able to send mail to myself.   I believe that no one tool or strategy can catch all spam but if you use a variety of tools than it is possible.  Spamhalter doesn't catch everything but what it misses is usually caught in my content control filters.  

 Jim 

DOes anybody know what ''you have exceeded your quota'' mean ??i am trying to open a document and this is the message i get after entering my username and password

traducere engleza:

DOes anybody know what ''you have exceeded your quota'' mean ??i am trying to open a document and this is the message i get after entering my username and password

Does this have anything to do with this 4-year-old thread about PayPal or is it about another product?

Perhaps if you can give us more information about exactly what you were doing when you get this error, we may be able to assist.