From: Lars Dybdahl
Sent: Monday, April 19, 2004 4:06 AM
Many knowledgeable people feel the same way about CBV. However, does
it
bother you more than SRS?
It certainly does to me. I don't see any reason to spend time on SRS,
since I don't have any forwards to e-mail accounts with SPF filters, and
SRS is irrelevant when sending e-mails.
Thank you for the input. That is what I asked for.
That is an interesting point. When there is a signed return-path, it
is
obvious that the sender invites a CBV to verify it.
The basic needs for e-mail communications are actually quite simple and
don't need call-back verification. What most people need, is:
- Being able to e-mail with friends. SPF and Autowhitelisting in
spamassassin makes this easy.
This is all post-SMTP. One of the important goals of SPF has always been to
detect envelope-from forgeries at the MTA and reject them _before_ DATA.
SpamAssassin is a wonderful tool, but like all content filters, it works on
complete messages _after_ reception. Doing SPF checks after accepting the
whole message is better than not doing them at all, but it throws away two
very important benefits: reducing the load on the MTA and reducing the
number of forgeries passed on to the user.
From the MTA's standpoint, once you accept a message, you have to deliver it
or send a DSN. If post-SMTP you discover that the return-path is forged,
the MTA's bandwidth has already been wasted, you can't send a DSN _and_ the
sender knows you accepted the message. All of those are undesirable. The
user doesn't see this if they have a good spam filtering solution, but the
people who purchase the network bandwidth and MTA resources are very aware
of this, unless they have an unlimited budget. Detecting forgeries before
DATA reduces the load on recipient MTA's, forces the sending MTA to deal
with undeliverable forgeries and sends less spam through to the MUA to
filter out. That was all part of the vision of SPF (and therefore SES) and
those are important goals.
- Be able to receive e-mails from new people you haven't e-mailed with
before. SPF/spamassassin makes a very good job at ensuring, that you
don't get spam this way. You can never protect yourself 100%, since the
definition of spam is depending on who you ask... Some people define it
as "unwanted e-mails", some as "e-mails you didn't ask for", some even
say that spam is defined by the law. There couldn't be more
disagreement.
Agreed. But SPF and SES are only about detecting envelope-from forgeries,
which is something that there is not a lot of disagreement on. It was meant
to bring some level of accountability to email senders and thus make it
harder for spammers to make a living. While the definition of spam varies
from user to user, no one on this list, unless I have missed it, has
suggested they want to receive messages where the return-path is forged.
The fact that many of the messages with forged return-paths happen to be
spam is a happy and useful coincidence.
- Be able to receive bounces. Cookies in sent e-mails are one way to
ensure, that you only get the correct bounces, so SES might be a
technique here, but CBV is not necessary.
The beginning of the SMTP session for a bounce and a CBV are identical, but
that is a technicality. As you suggest, SES is useful here, even if you
implement SPF.
Since SPF itself isn't about fighting spam, but about publishing
policies, I believe that the SES discussion doesn't belong on this list,
just as digital signatures like PGP and S/MIME don't either.
PGP and S/MIME are about verifying the originator and original content of an
entire message, including those headers created by the MUA. SPF and SES are
both about detecting forgeries in the return-path based on the domain
owner's policy and nothing more. I appreciate the fact that you don't think
SES should be discussed on this list, but it is really a discussion of flaws
in SPF+SRS and a search for possible solutions. It doesn't make much sense
to discuss that elsewhere.
1) I think that SRS creates enough serious problems to make it worth
looking
at alternate schemes that don't require such extreme measures.
SRS is not extreme, and you don't need to use it for all forwards. If
you forward to an e-mail address that whitelists the forwarding server,
SRS is not necessary at all. SRS is needed in certain cases, mostly for
mail providers that want to make it easy for their customers to create
forwards. For those, SRS won't be a big problem to implement.
Well, a lot of people do see SRS as extreme and it is probably the single
biggest impediment to widespread SPF adoption. We can certainly disagree on
whether or not SRS is extreme, but it is still a big issue, perhaps _the_
issue as far as SPF adoption is concerned.
Any intermediate hop that does not do SPF checks breaks the chain of
assertions that are necessary to give the destination gateway MTA confidence
that the original return-path was not forged. If that occurs, an SPF pass
at the last hop tells the receiving MTA nothing about the SPF status of the
claimed sending domain embedded in the return-path, which was the whole
raison d'etre for SPF in the first place. For SPF to work end-to-end as
intended, SRS is actually required at all intermediate hops. Whitelisting
of forwarders that do not do incoming SPF checks puts the mail right back
into the pre-SPF state: the recipient has no idea whether the claimed
originating domain in the return-path is forged or real. The mail will be
delivered, but we have gained nothing.
2) SPF checks are done at each hop in the message path.
No. It's done where it makes sense. The SPF checks don't specify where
to use it - you can be fully SPF compliant without checking for it...
Even the spftools checker doesn't check it for each hop in the message
path.
That's correct, each MTA only does an SPF check on the SMTP-client that is
handing it the message. In fact, the SPF model depends on _every_ MTA in
the message path to do an SPF check on the incoming message. If anyone
drops the ball, the game is over as far as forgery detection.
Because every site will take different actions with each SPF result
(the
standard does not even require sites to reject a message based on an
SPF
fail result), and sites will unfortunately differ in their
interpretation of
Freedom of choice... that's a good thing.
While I heartily agree with that in general, I can't agree with this in
regard to SPF checks. An SPF fail result says that the message source does
not meet the domain owners published policy for designated senders for their
domain. In other words, the message comes from a machine that is not
authorized to send mail on behalf of the domain and the domain owner wants
the recipient to know this. If a forwarder discovers this, yet does SRS
rewriting on the return-path and delivers it to the destination gateway MTA
anyway, the message will pass SPF checks at the recipient MTA. That
recipient MTA has no way of knowing during the SMTP session that the message
had an SPF fail result when it arrived at the previous hop. That is _not_ a
good thing, though it is compliant with the standard.
an SPF record, the final recipient can't have very much confidence in
the
SPF checks done previously.
The final recipient is human and doesn't care at all about how the
e-mail was delivered. The human just wants his/her e-mail to work well,
and wants a life where the letters SPF are related to cow and pig
diseases.
That's certainly what this is all about. Part of the notion of "email
working well" is receiving fewer forgeries in your inbox. Another part of
it is keeping the cost of email services down. While the end user may have
no interest in how these are accomplished, they are necessary to keep the
end users satisfied. SPF was developed to allow recipient MTA's to detect
forgeries in the return-path during the SMTP session and reject the message
before receiving it. For it to be effective as intended, the chain of SPF
checks along the message path cannot be broken and the SPF checks should be
done at SMTP time, not in the MUA.
3) I like the nifty "side effect" of being able to reject bounce spam
while
still accepting valid DSN's. There seems to be little disagreement on
this.
I think that's way outside the scope of this forum.
I appreciate your opinion on this. As an end user, SpamAssassin may take
care of forged bounce spam for you, but your MTA had to work overtime to
receive all that junk. For medium-sized ISP's and up, this is a very
significant issue. SPF can still do some checks on DSN's based on the HELO
string, because there is a null-envelope-sender, but SES rejects forged
bounces far better. I think that's germane to a discussion of SPF.
--
Seth Goodman