|
Re: Forwarding Methods Available with SPF
2004-06-06 23:22:07
Hi Michael (and spf team),
Thanks for the summary. Here are a couple of additional items to consider
adding or changing.
(I converted the table to plain text to show which part I am commenting
on...)
Overall Analysis:
______________________________________________________________________
SPF + DBBF
______________________________________________________________________
SPF + SRS
Forwarding Requires Modification to:
Forwarding MTAs
Advantages
+ No extensions to SMTP required.
+ Only forwarded addresses are modified.
+ No database storage required.
Disadvantages
(none)
The first two are pretty much "SPF Classic" so I won't spend a lot of time
on them. Your description seems mostly accurate, however, I would assert
that SRS has a heavy disadvantage to forwarders: They have to all implement
it
______________________________________________________________________
SPF + RSR + SES
Forwarding Requires Modification to:
Forwarding MTAs, Originating MTAs
As Stuart pointed out, I would drop SES from this table entirely. SES is
an optional extra step that some sites will choose to implement, and others
won't. It doesn't really have anything to do with forwarding, since you
can get bounces from other mailers even without forwarding. (Actually SES
could reasonably be added to any of the four options.) Removing SES makes
the rest of the SPF+RSR section make a bit more sense.
Most Serious Exploit Possible
SES encoded email address can be used to inject multiple forged bounces
on any MTA until the timestamp becomes invalid.
Seriousness
High
+ Forged bounces must come from domains that have passed SPF at injected
MTA.
- Victim's SES encoded email address is available to all receivers.
- Forged mails can be injected on any MTA.
+ Timestamp imposes time limit.
Advantages
+ No extensions to SMTP required.
RSR uses a deprecated syntax. Source routes are declared no longer
supported by a more recent RFC. Since it has been mothballed, and many
many MTAs don't support it, I would say that putting RSR back into active
use amounts to a change in SMTP. You would need an RFC to do so, or else a
force stronger than RFCs that causes people to update MTAs.
Therefore RSR has about the same problem as SUBMITTER in that regard,
except that SUBMITTER is optional for NewSPF+PRA, not required, whereas
OldSPF+RSR requires global adoption of RSR before we can turn off
trustedforwarders.org.
+ No database storage required.
Disadvantages
- Forged mail possible.
- All email addresses modified.
- Requires modifications to originating MTAs.
______________________________________________________________________
SPF + SUBMITTER
Forwarding Requires Modification to:
Forwarding MTAs
Receiving MTAs
I would suggest to call this section "NewSPF+PRA". SUBMITTER is not really
required to support forwarding in the NewSPF. This is a pretty important
point, and one that I think a lot of people have been missing.
The PRA (purported responsible address) is taken from the headers and is
the result of a carefully-crafted formula. It should identify who was
responsible for the most recent "hop" or "injection" of this message. This
could be an author, a forwarder, a mailing list robot, a greeting card or
other web site thing, or whatever. The headers and the order they appear
in the message are chosen carefully in order to most closely match what
most email messages already carry: Resent-From, Resent-Sender,
Delivered-To, Sender, From.
The point of using PRA is that forwarders can be modified to add a header
much more easily than modifying them to rewrite part of the envelope. In
fact, a number of forwarders already add either Delivered-To or
Resent-Sender, so they are already compliant with the NewSPF+PRA. If a
forwarder is adding the right header, they don't actually need to check
SPF; they should, but in the event they don't, the mail will still not get
blocked.
SUBMITTER is not required for forwarders in order to make the NewSPF
work... it is simply an optimization of the protocol to make the
information appear earlier in the process. IF there is enough support for
it among forwarders, eventually receivers will decide that MAIL FROM
without SUBMITTER constitutes a de-facto PRA, but if that never happens,
NewSPF trundles right along rejecting mail after DATA anyway.
Similarly, Receivers don't need to support SUBMITTER in order to get the
effects of NewSPF... the message can be rejected after DATA via
filter/milter, or if checking is done later down the line (e.g.
spamassassin) then all the info is in the headers anyway.
Given that, I would recommend:
change the title to NewSPF+PRA.
change Forwarding Requires Modification to: Forwarding MTAs -- Add note
(Add header if not already doing so. SUBMITTER parameter optional.)
change Forwarding Requires Modification to: Receiving MTAs -- to --
Forwarding OPTIONAL Modification to: Receiving MTAs (SUBMITTER optional,
can save bandwidth)
Most Serious Exploit Possible
Forged bounces can be injected by setting MAIL FROM to victim's email
address, SUBMITTER to domain with passing SPF policy.
Seriousness
Very High
+ Forged bounces must come from domains that have passed SPF at injected
MTA. - Any victim address may be used.
- Forged bounces can be injected on any MTA.
- No time limit.
I strongly disagree with this exploit being classified as "Very High". The
exploit is theoretically possible, but the spammer would have no reason to
do it -- it doesn't get his message in front of any extra eyeballs. Sites
that don't like this vulnerability are free to implement SES.
Advantages
+ No database storage required.
+May allow some protection against phishing.
+ No modifying of email addresses.
Disadvantages
- Forged bounces possible.
- Requires extensions to SMTP.
- Requires modifications to receiving MTAs.
These last two can be changed to "Changes to MTA optional, for possible
bandwidth savings"
OK that's all for now.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
|
|