From: Shevek
Sent: Friday, June 04, 2004 8:22 AM
On Fri, 4 Jun 2004, Roger Moser wrote:
Michael R. Brumm wrote:
Ok, anyone got anything written up on various implications of
resurrecting reverse source path for use with SPF?
And, if you need to add SES to reverse source path to prevent bounce
forgery, then why not just use SRS?
First, you cannot add SRS to a 64-character local part.
Second, SES is added by the original MTA only, whereas SRS has
to be added by ALL forwarders in the world.
By your description below, this is false. SES has to be added by the
original MTA AND all the forwarders.
I disagree with this statement. SES is only used by the originator. In an
SES-only system, forwarders don't modify MAIL FROM: at all. In an SES+SPF
system, forwarders can either use SRS or just add their unsigned domain to
allow SPF checks.
For example if example.com sends
MAIL FROM:<John(_dot_)Smith-ses-hash(_at_)example(_dot_)com>,
then the forwarder just has to prepend his domain name:
MAIL FROM:<@forwarder.com:John(_dot_)Smith-ses-hash(_at_)example(_dot_)com>
You can't add this to a 64 character local part for the same reason that
you can't do SRS in a strictly 64 character local part. The overheads in
the two cases are almost identical. This protocol requires modification
both on the forwarder and on the original MTA. In fact, it's logically
almost identical to SRS except for requiring the modification of the
original MTA as well.
That's correct, you always lose some characters to overhead. The overhead
is very similar to SRS, though slightly less, since there is no forwarding
domain in the local part. An example of an SES-signed return-path with a
forwarder using reverse source route format is:
MAIL FROM:<@forwarder.com:SES0=HHHH=TT=local-part(_at_)domain>
The overhead is "SES0=HHHH=TT=", which is 13 characters. This reduces the
available local part from 64 characters to 51 characters. As far as I can
tell, the reverse source route list is distinct from the local-part so it
does not reduce the number of available characters. You could use this same
formatting trick to reduce the overhead of SRS. In that case, the overhead
would be identical to SES.
--
Seth Goodman