Frank Ellermann wrote:
What you probably need need is to identify forwarders by
their HELO and IP against SPF or CSV or a "forwardmaster"
list of hardwired IPs (worst case).
No, that's not at all what is needed.
IBTD, in that case your idea wouldn't be better than say
trusted-forwarders.org and its variations like op=trusted
trusted-forwarders.org does not provide a complete list.
the list sent to the forwardmaster is expected and required to be
complete. Once the forwardmaster has a list for a particular user,
subsequent SPF "FAIL"s for that user will be rejected. As part of IT
planning, the postmaster may enforce a local flag day, as a date by
which all users must have stated their forwarded accounts. From that day
on, all "FAIL"s would be rejected. For those users who have sent a
list, "FAIL" means ALL forwarders's SPFs FAIL. For those users without a
list, the MAIL-FROM "FAIL" is sufficient to reject mail.
Greeting card sites? If they're unwilling to forge, maybe
trusted-forwarders may save them.
In your example:
1. 1.1.1.1 and sender(_at_)hotmail(_dot_)com against SPF record @
hotmail.com
You forgot step 0, where you check the HELO forwarders.com
against its policy. If you insist on a policy in step 2,
then step 0 should result in a PASS for the HELO.
I didn't forget it. The "HELO" check not a useful or reliable check as
far as I can tell. Other than RFC821 and 2821 alluding that it could be
the hostname/domain name respectively, neither makes it a requirement to
be a domain name, much less an FDQN.
Further, the name following the HELO is inconsequential to the SMTP
state machine, as no decisions are made on its contents. So it is a
"don't care" input. It is there to synchronize both sending and
receiving state machines to the "start" state. It's presence is of the
essence, not its contents. (for EHLO, the extensions have some meaning,
but the word following immediately the EHLO still have no use or
requirements)
Also, 1.1.1.1 can and probably is a mail aggregator. When vanity domains
are registered and email-forwarding is enabled, all those vanity domains
are forwarded through a single service. One SMTP server probably handles
hundreds or thousands of domains. So what is the meaning of the word
following HELO ? When you get letters, does the name of the postman make
any difference? I call my postman "there" as in "Hi there!".
So I do not see the need to do SPF or _any_ other checks on HELO.
It would be nice to skip step 1. In theory you have the
data to know that step 1 cannot / should not work for mails
from forwarders.com.
It's an implementation optimization. An intelligent implementation will
of course know which mail sources is a user more likely to receive mail
from (on a statistical basis, perhaps), and do the SPF checks on the
forwarded domains in order of most-to-least frequently used. Direct mail
also gets a statistical weight, such that if a user receives little or
no mail directly from a sender, the MAIL-FROM SPF check will be done
last, after all the other forwarders.
But this and other possible and needed optimizations are implementation
details.
2. 1.1.1.1 and account(_at_)forwarders(_dot_)com against SPF record @
forwarders.com
Two new ideas, the one I saw was "local white list based on
the RCPT TO", here you could reuse the result of step 0 with
a forwardmaster-list based on the FQDN forwarders.com
I missed our secod idea, the forwardmaster-list contains
complete addresses, not only the FQDN. Apparently that does
not work well for Web hosters or quasi-MX services, if they
forward all mails for a complete domain to recipient(_at_)example
Or could account(_at_)forwarders(_dot_)com be a "virtual address", only
used to get a "virtual identity" for your step 2 ? In that
case it would work, but you need another SPF test in step 2.
The "local" part of the MAIL-FROM email address is not used for SPF
other than to expand the "%{l}" macro. This macro will soon be
obsoleted, so it becomes a non-issue.
Even so, another implementation detail is support for wildcards.
*(_at_)example(_dot_)com
I'd opt for a HELO based forwardmaster-list. And then it's
as I said in the previous article, you have to be sure that
HELO forwarders.com is not forged.
Your choice. HELO is not a reliable basis for any processing.
Besides, when 1000 domains are forwarded by the same service (say
godaddy.com), the HELO will not be any of the 1000 domains being
forwarded, but mailout.godaddy.com.
Radu.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
smime.p7s
Description: S/MIME Cryptographic Signature