Subject: [Asrg] Re: Dangerous SPF

From: Douglas Campbell <[email-masked]>
Date: Sun, 29 Jan 2006 17:12:50 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Claus Assmann <[email-masked]>
Date: Sun, 29 Jan 2006 18:13:13 -0800

> So why don't the major MTA distros do this? 

man forward

---

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 30 Jan 2006 11:15:39 +0100

> > So why don't the major MTA distros do this? 

I'd like to belabor that a bit: Forwards are created by individual
users. So, unless you have very few users or a very tight policy, you
cannot really maintain a database of "trusted peers" for an MTA. Each
user would have to be able to maintain his own list of MTAs (by hostname
or IP addresses) from which he expects forwarded mail.

	hp

-- 
   _  | Peter J. Holzer    | Ich sehe nun ein, dass Computer wenig
|_|_) | Sysadmin WSR       | geeignet sind, um sich was zu merken.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |	-- Holger Lembke in dan-am
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg