RE: The open relay problem.

> From: Seth Goodman
> Sent: Friday, April 02, 2004 12:23 AM
>

Responding to and correcting my previous post.

>
> > 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.
>

<...>

> 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.

Neil and David are right and the explanation I gave above is rather
brain-dead.  I appreciate David pointing out my error.  I must remind
myself:  engage brain before typing.  The .forward file prevents the message
from being delivered to the mailbox and causes it to be passed on intact.
The bounce will be forwarded with MAIL FROM:<>, and since it has an unsigned
RCPT TO: address, it will be rejected at the SES host, just as Neil pointed
out.

Neil and David each proposed a solution, and the two are nearly identical.
Neil proposed a special signed reverse address format that included a hash
to be used from forwarding accounts.  This is an extremely clever way to
avoid any administration, once the mechanism is set up to generate the
addresses.  David proposed a specific, secret address at the SES host at
which SES checking will not occur.  They are functionally very similar.
Both act as whitelisted addresses for which SES checking will not be done,
but there is a slight difference.

In David's case, if the address were ever to be released or discovered, he
can just change it.  In Neil's case, the address remains good until you
change the hash secret.  Because of that, it would be best in Neil's
implementation to use a per user secret rather than a single hash secret for
the whole domain.  The easiest way to implement a per user secret is to
simply use each user's password as their hash secret.  That way, if a
whitelisted address does get discovered, all the user has to do is change
his password and the old whitelisted address will no longer work.  It also
affects only that user.  It remains a low administration solution.

SES works best, in general, if each user has their own hash secret.  When a
recipient does a CBV to verify the return-path and the hash secret is
different for each user, a valid hash verifies the user as well as the
domain.  That is something that SPF cannot currently do and it is valuable.

At first, it seems like a whitelisted address is a potential conduit for
spam.  In fact, it just allows you to receive the mail in whatever form it
is from another account.  It doesn't make anything better or worse.  SES can
only protect a host when that host signs all outgoing messages.  If the host
doesn't do this, it is vulnerable to bounce spam.  Once the host accepts a
message, the game is essentially over, just like with SPF.  Forwarding it to
another host cannot make it better nor does it make it worse.  If you have
an account that is not protected by SES, SPF or other forgery prevention
methods and you are going to accept the mail in that mailbox, it doesn't
matter if you pick up the mail directly or forward it to a whitelisted
address on another host.  The contents of the mailbox are the same either
way.

On the other hand, if the forwarding host does SES, it is protected from
bounce spam and forwarding from that account presents no problem, as the
account has the same properties as the host you are forwarding to.  Again,
the act of forwarding does not change the forgery detection properties of a
host.  It either does SES, SPF and/or other tests or it doesn't.

The longer example I gave is still correct, I believe, because the traffic
originated from a host that was SES protected.  That example just showed
that SES can run with or without SPF+SRS and it does not interfere with
their operation.

--

Seth Goodman