From: Frank Ellermann
Sent: Friday, September 10, 2004 2:53 PM
Jonathan Gardner wrote:
<...>
I don't see SPF Unified as adding much to SPF.
If there are cases where you can't control the MAIL FROM, but
at least know the MTAs sending mail with your 2822-From, then
PRA could be relevant. And if you can guarantee that the PRA
matches the MAIL FROM it doesn't hurt.
I have to agree with Jonathan and disagree with the representation you
make for PRA. SPF classic is simple and understandable, the identities
besides MAIL FROM: are not. The sender really should not be able to
control MAIL FROM:. That is the sending MTA saying who is responsible
for the mail and the user should not be able to forge this at will. If
you can't forge it, it is because the ISP has set it to the correct
value for the sending account. They are properly refusing to forge the
envelope return-path.
What few people seem to realize is that PRA, as well as SPF with
SUBMITTER or SRS, only authenticate the _current_ sender, they do _not_
validate the original sender, unless they happen to be the same. For
all forwarded mail, they are not the same. PRA will not look at From:
in forwarded mail because Resent-Sender: or Resent-From: will override
it. The original sender is all anyone really cares about, but for
forwarded mail, SPF+SRS/SUBMITTER/PRA today is incapable of making any
assertion about the originating domain.
If a domain publishes SPF, mail coming from a server that is not
designated should be rejected at the first hop. Because of the focus of
PRA, SUBMITTER and SRS on the _current_ sender, spammers have an
excellent way to spoof originating domains by simply posing as
forwarders at throwaway domains with proper SPF records. They can do
SRS, add a Resent-From: header and provide SUBMITTER, and the recipient
will extract the forwarder's domain as the responsible sender. If the
forwarder's SPF record is in order, the recipient will accept the
forgery. Proponents of reputation systems will say that you need
reputation to sort out forwards, and others will say you need a list of
trusted forwarders, but that's only because of a basic flaw in the
original authentication mechanism.
SPF authenticates the original sender on the first hop only. Beyond
that hop, the SRS, SUBMITTER and PRA forwarding schemes validate the
address of the forwarder rather than the message originator. The SES
(signed envelope sender) forwarding mechanism does not have this
problem. Regardless of the number of forwards, it _always_ validates
the return-path domain and thus prevents joe-jobs for any recipient that
uses it. It has the worthwhile additional property of rejecting any
null-sender messages that are not in response to a message that you
actually sent out.
Combining SPF classic with SES works as follows. When the originating
gateway MTA sends a message, SPF will naturally give a pass since the
MTA is designated, so SES is not used. On a forward, an SPF classic
check on the return-path will fail, as the forwarder's MTA is not
designated. In that case, the recipient does an SES validation with the
originating domain and finds out if the message is valid or a forgery.
There is no need for the extra ESMTP parameter SUBMITTER, there is no
need for forwarders to change existing practice, as required by PRA, and
any recipient MTA can validate the authenticity of the claimed message
originator. Reputation systems can still inform the decision to accept
or reject mail, but now they can work with a _validated_ originating
domain, which is not possible on forwarded mail with SRS, SUBMITTER and
PRA.
--
Seth Goodman