spf-discuss
[Top] [All Lists]

Re: possibilities for 2822 (was SPF implementations)

2005-08-17 12:21:43
On Wed, 17 Aug 2005, Seth Goodman wrote:

The only things we've lost by insisting that the From: or Sender: domain
matches the MAIL FROM domain is one anonymizing mechanism and a clear chain
of remailing events in the rare case that intervening MUA's or MTA's
actually support this.  We still have the Received: headers, so the path
information is not lost.  In a time when we have to authenticate the origin
of messages in order to assign responsibility for abusive behavior,
trivially achieved anonymity may be a necessary casualty.

This is actually a good idea.  It could be called 'Sender-ID Lite'.
By matching only domain, MAIL FROM signing techniques continue
to work.  I would suggest that MTAs should not reject based on From/Sender
domain not matching MAIL FROM, but that MUAs should simply highlight 
a From or Sender that doesn't match with "POSSIBLY FORGED" warnings.
If MUAs don't do that, an MTA could add "[POSSIBLY FORGED]" to the Subject,
or otherwise flag the mail without rejecting it in a manner visible via
the MUAs behind it.

Question: do we require an *exact* domain match?  What about 
MAIL FROM <foo(_at_)mx1(_dot_)bar(_dot_)com> and From: <baz(_at_)bar(_dot_)com>?

I will start doing your proposed check in pymilter and logging possible
forgeries.  This should give us an idea of how feasible it is.

Quick, someone with $100 and lawyers fees to spare, file a patent for
the open source patent pool before some jerk sends you a cease and desist
letter for your own invention.

-- 
              Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.