Re: when spoofing isn't

Hello-

I agree with Wayne and Yakov (and others) that validating RFC2821 MAIL FROM 
is "a good place to start".
I would *like* to see some more controls on the RFC2822 From: and other 
headers, but frankly, I don't think we have done enough research and field 
testing to support those controls -- yet.  (Or perhaps we have and the 
results haven't been distributed widely :)
Similarly, I think RFC2821 HELO checking can produce some useful results 
(especially in blocking really blatant forgeries like HELO microsoft.com or 
HELO using the recipient's own domain.)  But, I'm cautious about this as 
well.
Let me throw some ideas out here and you can all either praise or mock them 
:)  Points 1-4 below can be taken individually or together in 
combination...  If you disagree with any of 1-4 please say which ones you 
do or don't agree with for the sake of clarity.

1. RFC2821 MAIL FROM identified as Phase One of the designated sender 
program.
 Pros:
 + Mail can be blocked before DATA phase, saving bandwidth
 + Helps to reduce bounce-spam, which is an incentive to adopt
 + Visible to users and helpstaff as "Return-Path" (usually)
 Cons:
 - "Nearly invisible" to novice users
 - Doesn't effectively stop phishing or other forgeries aimed at tricking 
users
 - Need a "fallback plan" for MAIL FROM: <>


2. RFC2822 From: Sender: etc. calls for "more research and testing"
 Questions:
 ? In a large/diverse set of "good mail" does Return-Path match one of 
From, Sender, Resent-From, Resent-Sender?
 ? If there is a strong correlation, would we benefit by warning the user 
when the Return-Path *doesn't* match one of the headers?
 ? In the case of VERP (and SRS) Return-Path will not match.  Can we 
decode the Return-Path and match, or can we get a partial match only on 
domain?
My guess is that RFC2821 MAIL FROM will match From: or Sender: most of the 
time.  But, spammers/phishers are crafty- if MAIL FROM / Return-Path 
validation starts in earnest, they may start to diverge from this. 
Spammers will change their behavior a lot faster than admins will update 
their normal MTAs.  If we want to validate RFC2822 From: address as Phase 
2, let's start this research now.  If we can anticipate the logical "next 
move" by the spammer we can be ready.

3. Provide recommendations to MUA developers, but don't depend on them for 
our efforts to succeed.
MUA developers can take advantage of our efforts right away, by way of
 * Allow the user to view Return-Path
 * Allow the user to view sender authentication info if present in headers
 * If sender authentication succeeds, and the From: address matches it, 
provide some visible feedback (such as a green check mark next to From:)
 * If sender authentication presents any warnings (such as 
From:/Return-Path: mismatch) provide visible feedback (like a ! mark next 
to From:)
However, assuming NO action on the part of MUA developers, we could provide 
some results to the user right away.  These could be optional features that 
the receiver's MTA could turn on or off as appropriate:
 * Possibility to add text to the From: address (not <addr> part but 
"Visible" part) such as "(unverified)" or "(possibly forged)"
 * Possibility to add text to the subject
 * Possibility to add text to the body of the message, though in the case 
of MIME we would have to proceed carefully.
 * Possibility to defang the MIME parts and substitute our own visible 
part, similar to Spamassassin ("This message may be forged. The original 
message is added as an attachment.  Some suspicious attachments have been 
dropped. etc")

4. Some checking of RFC 2821 HELO might be helpful but this should not be 
the main focus of the sender authentication effort.
For example, SPF uses HELO as a fallback when MAIL FROM: <> - in this case, 
you would limit your possible "false positive" result to blocking bounce 
reports from badly-configured mailers, and those mailers could still send 
you normal mail, just not bounces.
However, some users have reported that they get really great results from 
blocking "obviously forged" HELO names, and leaving other questionable HELO 
results alone.  For example, my servers might HELO with "mail1.example.com" 
or "mail2.example.com" and no legitimate server should ever HELO with just 
"example.com", so I can safely block those.  There may be servers with 
short (mail1), private (mail1.corp.internal), or obviously fake 
(localhost.localdomain) HELO names but we probably don't want to tackle 
those yet.  More research/testing would be good here too.
Therefore, HELO may not want to be included in Phase 1 - we may choose to 
focus only on MAIL FROM for Phase 1, so that we don't blur the message or 
confuse people... but I don't have a strong opinion here so I'm interested 
in everyone else's feedback.  Who knows... if we could provide a 
conservative strategy for HELO and roll it out, that might add lots of 
great results for relatively little cost.

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>