RE: Question abour SRS in sendmail

"Seth Goodman" <[email protected]> Tue, 19 Jul 2005 18:06:10 -0500
Newsgroups gmane.mail.spam.srs.general
Message-ID <[email protected]>
> From: Stuart D. Gathman
> Sent: Tuesday, July 19, 2005 10:37 AM

<...>

> SES is great for signing the return path.  But it doesn't help
> with delivering bounces for forwarded mail.

With SES, as with ordinary email, a bounce from any MTA in the message
delivery path goes directly back to the originating gateway MTA.  If that
MTA can validate the signature on the null-sender message it is being
offered, the message is very likely a bona-fide bounce and it should be
accepted.  This is no different from the way bounces work today, except that
the original sender has a tool to help distinguish forged bounces.


>
> Some people use SRS only to block forged bounces - and SES could be
> an alternative for that purpose.  But for forwarding mail and
> any resulting bounces, SRS is what you need.

While SRS is one way to accomplish forwarding broken by SPF, SES integrates
more easily with SPF without the cooperation of any forwarders or the final
recipient, for that matter.  One implementation of this only does the SES
validation check if the message does not otherwise yield an SPF pass.  This
can be accomplished, even for SPF recipients that have never heard of SES,
by use of the exists: mechanism with appropriate macros and a "stunt" DNS
validation server.

While this is not my favorite implementation for SES, it only requires the
original sender's cooperation and does solve the forwarding problem inherent
in SPF.  The original sender would preferably set things up so any DNS
validation requests for SES are routed back to the originating gateway MTA.
There is _not_ a real DNS server in that MTA, only a process that accepts a
UDP query (that happens to be in the form of a DNS request packet), checks
validity of a signature and issues a UDP response (that happens to be in the
form of a DNS response packet).  The SPF-compliant recipient will not know
that it is not talking to a real DNS server, only that the exists: mechanism
just matched, thus generating an SPF pass.

The end result is that due to an action taken only by the original sender,
mail leaving that sender and is subsequently forwarded will generate an SPF
pass at any SPF-compliant recipient.  This does not require the recipient or
any of the forwarders to change anything.  Bounces also go directly back to
the originating gateway MTA and need not be relayed by a forwarder.  If this
sounds like what you want, SRS is most assuredly _not_ what you need.


--

Seth Goodman