Frank Ellermann said,
That's a dangerous idea. You must know what you're doing if
you enable it. You can only use it at your border MTAs, you
have to white list them if they talk with each other (normal
MX priority scheme as explained in RfC 2821), and you have to
make up your mind about the weird 1123 5.3.6(a) forwarding to
you from third parties. Ignore them, white list them, talk
with them, whatever you do, it's more than only "enabled by
default". Mininmally you'd know why you use (or don't use)
trusted-forwarders.org.
I'm at a loss here as to the danger. But regardless of the danger, where
is SPF, enabled by default or not, in the major MTA implementations?
Why isn't it part of them?
Avoiding the danger you describe seems easy in my mind:
For a domain, the SPF records define a database of border MTAs who are
allowed to send mail directly to foreign addresses.
The MX records of a domain define a database of border MTAs who are
allowed to receive mail directly from foreign addresses.
An MTA commonly has a database of trusted peers as well (it will accept
local or foreign mail from these peers with no questions asked). I
assume the existance of such a database for this discussion.
I believe that if an MTA is in the MX database for its domain, default
enablement of SPF for that MTA is correct. Therefore, enable SPF, but
don't use it for trusted peers.
If an MTA is not in the MX database for its domains, and is in the SPF
database, it is allowed to utilize MX records of foreign domains to
deliver mail. Do not enable SPF, and only accept mail from trusted peers.
If an MTA is not in the MX database, and is not in the SPF database, it
can only use MTAs in its trusted peer list as a target for forwarded
mail, and cannot deliver mail to any other peers. Do not enable SPF.
The above sounds like a reasonable scheme for autoconfiguring SPF
operation by an MTA. It doesn't seem hard to implement, since it
relies on the content of exactly three databases -- the one contained in
the SFP records, the one contained in the MX records, and the trusted
peer list.
So why don't the major MTA distros do this?
Cheers,
Douglas Campbell
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg