spf-discuss
[Top] [All Lists]

Re: Email Forwarder's Protocol ( EFP )

2005-02-25 17:49:31
At 12:26 AM 2/25/2005 -0800, you wrote:

On Tue, 22 Feb 2005, David MacQuigg wrote:

> At 01:24 AM 2/23/2005 +0100, Alex wrote:
>
> >Trace headers have a long history...  Are you sure this is "new" ?
>
> Using Received: headers is certainly a possibility, but I think there may
> be a problem with too many variations in existing formats, and the need to
> cram in more information to support authentication protocols.  As I
> understand it, the format of the these headers is not adequately
> standardized. If we try to define it more precisely, we may break existing
> programs.
>
> RFC2822 defines the Received header as follows:
> received  =  "Received:" name-val-list ";" date-time CRLF
> I can't find anything further on the details of the name-val-list.  Has
> this been formalized in some other document?

Read RFC2821, you'll find it defined in better detail there with list of
some possible tag names with possible standard values.

Thanks. Section 4.4 "Trace Information" is excellent. It says very clearly that the FROM field of a Received: header MUST be provided and SHOULD contain the source host (from the EHLO command) and the IP address of the source, determined from the TCP connection. Of course, the EHLO name could be forged, so to make this useful as a forwarder's authentication header (and distinguish it from Received headers that make no statement at all about authentication), we would need to add a few more words to the FROM field. Maybe "auth=SPF1 PASS" or something like that.

We can then use the Received: headers for the bounce path instead of bouncing directly to the forged Return-Path:. If the mail is legit, sending it back along the bounce path will get it to the same place as the Return-Path. If its a forgery, the bounces will stop where they should, at the forger's domain, and not bother anyone at the forged Return-Path.

So to make SPF work with forwarders, we don't need any new headers, just a few more words in an existing, widely accepted header, and an agreement on how forwarders should handle bounces.

Am I missing something?

-- Dave