Daniel Taylor <dtaylor <at> vocalabs.com> writes:
Radu,
You had some really good points wrt the whole DNS query loading, but I
am really not following your logic here.
Hi Daniel,
Thank you for giving me the opportunity to clear up any of the
logic I may have misscommunicated.
ASSUMING you bother to check HELO as well as MAIL FROM with SPF, it
gives you two chances to reject instead of just one. Any result that
does not result in a reject leaves you with an e-mail message to
deliver.
Is that such an awful thing, that you have to deliver a message?
SPF already gets the FAIL wrong when a piece of mail arrives via
a forwarder. do we need another opportunity to get it wrong?
There are really several reasons why I oppose HELO checking with
SPF. Here they are, in order of importance, as I perceive it:
1. Checking HELO is unreliable, and may cause more mail bounced.
Let's not get carried away with bouncing email. When a domain
owner specifies what mail should be accepted and what mail
rejected (ie, the official SPF record), that is the only wish
he has. If he wanted you to bounce mail from certain other
servers, he would say so. Certainly he has the -all mechanism
to use. There is nothing more a HELO check can tell you about
the domain owner's wishes than the MAIL FROM check does. In
fact, as a domain owner myself, since my mail goes through
unknown-to-me paths (forwarders, backup MXs, etc), I'd much
rather know how my SPF record will be interpreted. If as a
recipient, you make decisions on factors I don't know about
(ie, some SPF record of a mail server host controlled by an
incompetent ISP along the way), I'll have hell debugging why
my mail to you gets bounced. The mail communication would
become less reliable withthe addition of HELO checks.
2. There is a another good abuse opportunity by spammers. Say
that in order to bypass the HELO SPF check, they hardcode the
hostname of an innocent small domain that needs wildcards into
their spam engines. Then they use that domain's wildcard for a
supply of HELOs. Since each such software probably sends
billions of emails during its lifetime, the cost to the
innocent domain would be a lot. This can constitute DOS.
3. The mechanism of MUA submission via port 25 has not been
studied enough. Perhaps a majority of users currently use this
method of submission, and perhaps a large percentage have no
need to switch. The trouble is that MUA's cannot be trusted to
generate a HELO that would not cause PermError, or other such
SPF results. This would be a tech support issue, that I am
sure most ISP's would rather not tackle. So the
recommendation to check HELO with SPF does not jive well with
a lot of ISPs.
4. Checking HELO only gives you the warm fuzzy feeling that your
a little safer from forgeries. As I have shown, the HELO domain
word has almost nothing to do with the rest of the message, and
it is inconsequential. I believe I showed this quite clearly,
but I can try other ways if necessary.
5. Checking HELO has the potentially to double the overall DNS
load that SPF adds to the Internet. It is a very high
load even before doubling it, considering the 111
queries of previous specs, and the infinite queries
of the present one. Think of the queries not only
in terms of actual load to DNS servers, but also
to the degradation in performance of a receiving MTA that
has to wait many seconds until all the serialized
queries come back. I would not suggest parallel
queries; for the SPF application, serial is better.
Yes, DNS load is a consideration, and so are other issues, but they have
to be weighted against the other considerations.
100 DNS queries is still less traffic than a typical spam message.
It is _much_ less than a typical e-mail worm/trojan.
Be cautious that in lightening your load for a long trip, that you don't
leave your canteen behind. Water is heavy after all.
DNS load is actually the least of my concerns with repect to HELO
checking. This recommendation has far worse problems than just
being inefficient. (I regard using up more DNS resources merely
as an inefficiency).
Perhaps this is why I seem to be jumping around, because there
are several issues that worry me at the same time.
Regards,
Radu.