RE: The open relay problem.

> From: Neil Brown
> Sent: Wednesday, March 31, 2004 7:07 PM
>
>
>
> Hi,
>
>  I've been thinking a lot about the "universal-SRS" idea and am
>  definitely warming to it.

Glad to hear it.  You're definitely not alone.  Meng previously suggested
that we call this scheme "Signed Envelope Sender" (SES) to distinguish it
from SRS, so I will refer to it that way from now on.

>
>  However I just noticed something else that it could break.
>
>  Suppose I have an address like [email protected] (which I do), and
>  suppose I forward mail from there to [email protected] (which I
>  also do).
>
>  Now suppose I chose to send mail so that it appeared to be "From"
>  [email protected] (which I do very occasionally), and suppose that I
>  sent this through an MTA which is authorised for "brown.name" in what
>  ever way is appropriate (e.g. SPF) (which I don't think I can for
>  brown.name, but I definitely can for some other forwarders),
>
>  And suppose that this mail I send results in a DSN that I really want
>  to see.
>  It will get to the authorised MTA address for [email protected]
>  (possible wrapped up in SRS if the MTA does that) and the MTA will
>  forward it to [email protected].  But obviously that MTA cannot
>  wrap the to address in an SRS that we will accept, so my (cse) MTA
>  will get Mail From:<>, Rcpt to:<[email protected]> and my MTA
>  might feel inclined to reject it. Which I would rather it didn't.

Let's first assume that you sent the original message by logging into the
forwarder at which you have the [email protected] account.  In this case, the
From: and Reply-To: will be [email protected].  Let's say that this forwarder
also uses SES.  Since the domain brown.name has a valid MX record, the
forwarder's MTA will set the return-path on your outgoing message to:

[email protected]

The domain name appears twice in this address, which is wasteful, but this
is necessary if we want to be compatible with SRS.  If the forwarder
chooses, they could alternatively set the return-path to:

SRS0=HHHH=TT=brown.name=neil@forwarder

If a DSN comes back to either of these addresses, the address will be
unwrapped and DSN delivered to the mailbox for [email protected] as the final
destination.  The DSN is now a regular message in that mailbox and is no
different than any other message.  Since this is a forwarding account, the
DSN will be forwarded as a regular message, not as a null-sender DSN, back
to your university account.  Using SES in this case does not break anything.

Let's look at a much more elaborate case and see if things still hold
together.  You send mail from your university account but make it look like
it came from your personal account.  Let's further assume that all the MTA's
use SPF+SRS and your university outgoing MTA uses SES.  To make things more
interesting, the recipient address that you send the message to is a
forwarder.  Here is the message flow:

1) In your mail client at the university, you change the settings to:

From: [email protected]
Reply-To: [email protected]

and send the message through the account [email protected]

2) The university MTA uses SES and sets the return-path to:

[email protected]

3) Your university MTA starts an SMTP session with "forwarder" and gives the
SRS0 address above as the MAIL FROM: address.  "forwarder" does an SPF query
for "cse.unsw.edu.au" and verifies that the SMTP-client is a designated
sender for that domain.  The SPF result is pass, so it accepts the message.
Being a forwarder, it changes the To: address to the final recipient
address.  Since it sees an SRS0 address in the return-path and it is an
SRS-compliant forwarder, it rewrites the return-path to:

SRS1=HHHH=cse.unsw.edu.au==HHHH=TT=cse.unsw.edu.au=neilb@forwarder

4) The forwarder starts an SMTP session with the final recipient's MTA and
uses the SRS1 address above as the MAIL FROM: address.  The SPF result is
pass, so it accepts the message.  After a few days, the MTA cannot make
final delivery and gives up.  The MTA starts an SMTP session with the MX for
"forwarder" to send a DSN.

5) Since the MX at "forwarder" sees MAIL FROM:<>, it does an SPF query on
the HELO name and the SPF result is pass.  It responds "OK" and gets the
RCPT TO:<SRS1_address_from_step_3>.  It verifies the SRS1 hash and then
accepts the DSN.  It unwraps the return-path back to the SRS0 address in
step 2 above and starts an SMTP session with the MX for "cse.unsw.edu.au".

6) Since the MX at "cse.unsw.edu.au" see MAIL FROM:<>, it does an SPF query
on the HELO name and the SPF result is pass.  It responds "OK" and gets the
RCPT TO:<SRS0_address_from_step_2>.  It verifies the SRS0 hash and then
accepts the DSN.  It unwraps the SRS0 address and delivers the DSN to the
"neilb" mailbox.

7) If the mail is successfully delivered to the final recipient in step 4
instead of failing, the recipient will see "From: [email protected]"
displayed.  If the recipient replies, the mail will be addressed "To:
[email protected]", which will then be forwarded to your university account.
However, if they look at the top of the detailed headers, they will see:

Return-Path:<SRS1=HHHH=cse.unsw.edu.au==
   HHHH=TT=cse.unsw.edu.au=neilb@forwarder>


As you can see, SES does not interfere with either SPF or SRS and can play
with or without them.  Of course, this would all be a lot simpler and cause
less breakage if we didn't do sender rewriting.  If we didn't have to worry
about compatibility with SRS, the return path would be shorter, particularly
the local part.  For example, your university MTA could sign your
return-path as:

[email protected]

This is a real pity since SES gives the recipient more confidence in the
origin of the email than SPF+SRS without any of the breakage and doesn't
require anyone else to cooperate.

--

Seth Goodman