David MacQuigg wrote on Saturday, January 27, 2007 12:19 PM -0600:
I suggest a simple, efficient hierarchy in authentication tests:
1) Check HELO to verify an entire session with a sender. Senders
with sufficient reputation need no further checks. All mail in
that session can go directly to the recipient's inbox.
2) Check MAIL FROM on each non-whitelisted message where the
Return Address domain differs from the HELO domain. Again
whitelist any that qualify.
3) Check the contents of the message using DKIM, or whatever
other method the sender might offer.
4) Run the remainder through the usual IP blacklists and spam
filters.
A very rational description of applying reputation to three envelope
sender identities: IP, hostname and MAIL FROM domain. This can be a
simple match/no match scheme like SPF record evaluation, or a scoring
system where you process reputations until you accumulate enough points
to make a decision. While it's not clear that it's really necessary,
tracking reputation for all three identities gives you the most chances
to produce a definitive answer. The order that you confirm identities
and process reputations is arbitrary. If you add recipient identity,
you can have per-user policy. You can also use heuristics like a banner
pause and hostname regexp looking for dynamic IP's before doing
anything.
IP is confirmed by TCP and available immediately, and IP blacklists are
currently more comprehensive, so let's arbitrarily assume the evaluation
order is IP, hostname then MAIL FROM. You first check IP reputation and
if not adequate to make a decision, you move on to host domain. SPF
pass on HELO confirms the host is a designated mail sender for its
domain, so look for that first. SPF fail is only definitive with
op=helo, which is rare. For SPF fail without op=helo and SPF neutral,
you could try to confirm the hostname through DNS by matching PTR to A
records. If DNS confirms hostname, you can then check reputation for
either host domain or FQDN. I can't think of a scenario where SPF fails
on HELO yet hostname confirms through DNS, so I believe this is a safe
fallback, though it could result in many DNS queries.
If you still have inadequate information to make a decision, go on to
MAIL FROM. Most of the time, the MAIL FROM domain is the same as HELO
domain, so you if HELO confirms you have confirmed MAIL FROM. SPF fail
is also indeterminate in this case unless you are able to track all your
users forwarders. For SPF fail with no forwarder whitelist or SPF
neutral, you could still try to confirm MAIL FROM via DNS. Like HELO, I
don't believe this is abusable, though it increases the number of DNS
queries when the MAIL FROM domain is different from the HELO domain.
These ideas of falling back to DNS to confirm identities have been
around a long time, and I believe Stuart mentioned them previously.
It's not as good as SPF pass, which tells you that a host is designated.
Since not everyone publishes SPF, and some systems have misconfigured
HELO names, and most systems don't whitelist their users' forwarders,
this fallback seems a reasonable compromise. The alternative is some
kind of return-path rewriting (SRS or SES), which is easy for recipients
but harder for senders. The DNS fallback scheme is complicated for
recipients but easier on senders.
SPF could expand its scope to include a robust check of the HELO
name, but until that happens, SPF authorized senders can simply
publish "helo=spf" at _auth.<domain>, and anyone using our
Registry take that as permission to REJECT any use of their name
that doesn't pass the HELO check.
I agree with Stuart that since there is already an ID for op=helo, it
seems inappropriate to encourage a competing ad hoc arrangement. You
could, however, use op=helo in exactly the same way and point people to
the draft for guidance.
--
Seth Goodman
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735