From: Meng Weng Wong
Sent: Tuesday, September 14, 2004 10:08 PM
<...>
But if we want to remove the SRS requirement for forwarders
without weakening protection for the other identities, we
would have to require either one of two things:
1) that we make HELO checking mandatory for receivers, and
that receivers be easily capable of whitelisting
forwarding systems by that identity, or
2) that we make SUBMITTER mandatory for forwarding senders
and receivers.
The third and best option:
3) Use an end-to-end adjunct protocol like SES. This solves the
forwarding problem without forwarders doing anything new and without
creating a new ESMTP parameter.
Of course, we would also specify that a positive result
(where auth+policy both pass) would override failures
elsewhere in the system.
Note that the trusted-forwarder.org checking in most SPF
Classic implementations essentially sneaks the first benefit
into the system, by way of a PTR identity. That first rule
changes that to a HELO identity, but provides the same
benefit.
Any form of forwarder whitelist degrades the utility of any reputation
system you care to use. The originating domain is the entity who's
reputation you care about. With a forwarded message, SPF cannot by
itself validate the originating domain. SES can do that and it does so
without breaking anything else.
If consensus does not oppose HELO checking, then a
"unification" draft could require that receivers always
check the HELO identity (setting aside questions of protocol
and syntax). Also mandatory would be the return path,
SUBMITTER (when checking before DATA), and PRA (when
checking after DATA) identities. This choice of identities
is justified by the following argument:
Making HELO-checking mandatory should satisfy folks who want
to get their MTAs whitelisted easily. This includes ESPs
and forwarders.
Checking the return path would satisfy folks who want to
limit unauthorized use of their domain names in the return
path.
Checking the SUBMITTER and PRA identities would satisfy
folks who think validating those addresses will help with
phishing.
Making SUBMITTER and PRA mandatory is a real problem. PRA is not only
volatile, untested and known to permit originating domain forgeries in
the case of forwards, it contains encumbered IP. Whether or not you
call it Sender-ID, it is still covered in MS's patent application and a
number of key MTA sources have already said they cannot support anything
thus encumbered. I think it's time we agree that for all intents and
purposes, PRA is dead due to its inability to achieve wide adoption. If
we want to come up with something smarter for 2822 validation then let's
do that, but this dog just won't hunt. It can't hunt because it's dead
and it was born that way.
SUBMITTER also requires a change to SMTP, which is unnecessary if you
consider using SES to fix your forwarding problem. SES is lightweight,
does not burden DNS, it is immune to replay attack, it positively
identifies the originating domain in the return-path and stops joe-jobs
cold, which SPF cannot do on any forwarded message. I'm sorry that SES
was not thought of first by the SPF "inner circle" or by Microsoft, but
those are poor reasons to ignore it. It's here and it can solve the
problem with less breakage than any other approach.
If folks agree, it might be useful to standardize that set
of identities in the "must check" list.
I think that putting SUBMITTER and PRA into a MUST check list would be a
serious mistake. Checking the return-path obviously has to be required
and I have no argument with requiring HELO checks. It is not hard to
configure HELO correctly and people will do it if it threatens their
mail delivery. The RFC's obviously intended HELO to be properly
configured, even if there were all manner of weasel words to cajole you
into accepting mail from misconfigured hosts. Today, we cannot afford
to be quite so liberal in what we accept, since most of it is garbage
and we have to pay for it. It makes sense to start enforcing some of
the clearer intentions of the RFC's, even if their requirements were
written at a time when more liberal acceptance made more sense than it
does today.
The essential difference between the HELO identity and an IP
address is that it's easier for a receiver to whitelist
*.mta.example.com and not worry about IPs. This is one big
driver in the ESP->ISP whitelisting relationship.
The essential difference between the HELO identity and the
PTR, both of which are (nominally) hostnames, is that it's
easier for senders in some parts of the world to set up
forward-lookup (domain -> SPF/TXT/A -> ip) mappings than
reverse-lookup (ip -> PTR -> domain) mappings due to PTR
delegation brokenness. Also we have been asked by the DNS
people to refrain from putting additional load on the PTR
system if possible.
Maybe so, but rDNS is the only way to find out if the FQDN in the
forward DNS actually belongs to the party claiming it. I sympathize
with the DNS people's request, but I don't see the rDNS check going
away. It is simply too useful of a spam indicator to ignore, and it is
the first test most well-configured MTA's do on an IP requesting a
connection. It also is very helpful in identifying dynamic IP's.
--
Seth Goodman