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

 

---

--
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme@yamta.org
http://sabahattin-gucukoglu.com/

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.