Initial thoughts.

[David Woodhouse]

On Tue, 2004-02-24 at 14:45 -0600, Seth Goodman wrote:
> Here is my own personal list of possible goals for something better than
> the current SPF+SRS, some of which were already listed by others.

Some of these are redundant. #1 and #2 are basically the same, for
example -- 'permit an interested party to detect sender forgeries.'

That aside, they're all basically sane, although...

> 4) Permit a gateway SMTP-recipient (or perhaps the user MUA?) to detect
> and reject certain header forgeries after DATA (authenticate DATE:,
> FROM:, TO:, etc. headers at the receiving end). 

Date: and From: I'll grant you. But To: gets rewritten and I'm not sure
it needs to be verified. You don't learn a lot from the To: header. 

> 10) Don't create replay exploits, if possible.

It should be noted that being able to replay the same mail _if_ it also
contains the same body, and isn't a new spam piggybacking on a
previously signed message header, is acceptable.

I think it's a _good_ thing, in fact. I'll elaborate in a moment.

> I put a high value on being able to reject mail before DATA, or at least
> immediately after the DATA command but before receiving the data, as
> some have argued for. 

Yes, absolutely. As much as possible should be done before accepting
DATA.

But checking _after_ receiving the data is the only way you can check
certain things, and this also prevents you from the moral duty to
generate bounces, if you reject before _accepting_ the data.

> 5) Upon receiving the message data, verify sender_sig2 using the public
> key for the domain.  

> b) No callbacks are required in this implementation, but an alternate
> implementation using them is possible.  Specifically, the verification
> of sender_sig1 in step 5 could be replaced by a sender callback.

This is a very good idea. Using public/private keys for signing your SRS
addresses allows interested third parties to _know_ that it's a real SRS
address generated by you.... and hence this could actually help to
alleviate the multiple-hop SRS problem too.

That is, you rewrite an SRS1 address back to an SRS0 address at someone
else's domain _only_ if they're publishing the pubkey records and the
hash checks out.

-- 
dwmw2