From: Michael R. Brumm
Sent: Sunday, June 06, 2004 4:04 PM
Take a look at:
http://www.michaelbrumm.com/spf-forwarding.html
Let me know if there are any mistakes.
Under SPF + RSR + SES, Exploits, seriousness, you list:
- Victim's SES encoded email address is available to all receivers.
This situation is identical for SRS. Destination gateway MTA's should strip
the signature part out and just prepend the Return-Path: header as a plain
email address, just as we require for SRS. Only mailers belonging to
malicious parties will pass on the signed SES address to the recipient. And
just as with SRS, only malicious parties will use the signed address for
spamming. However you treat this for SES, you should treat it the same way
for SRS. IMHO, the victim's signed return path is only available to
malicious users for _both_ SRS and SES if you send an email to that
malicious user. The signed addresses are not generally accessible by end
users for either protocol and are not available on mailing lists or other
common means of harvesting addresses.
- Forged mails can be injected on any MTA.
This is not correct. If you are a user on an MTA and tell it to act as a
forwarder for an unknown third party, that amounts to open relaying. You
have to have control over the MTA to make it send the forged forward
message. Unless you have control over all MTA's, that statement is
incorrect.
As a note to make things clearer, reverse source routing has nothing to do
with SES, though I happened to use the RSR format to transmit the current
sender information in the message that you link to. RSR was proposed as an
alternative to SUBMITTER, and it performs the identical function, albeit
using a different mechanism so it has slightly different strong and weak
points. SES is independent of RSR, SUBMITTER, SPF and SRS. It is solely
for the purpose of allowing an MX to reject forged null-sender messages
before DATA.
--
Seth Goodman