
radu.spf at ohmi
Mar 31, 2005, 8:29 AM
Post #1 of 3
(401 views)
Permalink
|
|
[Fwd: What is the recipient's "local policy" ? (l=)]
|
|
> SPF has left itself open to this criticism by not having a clear > policy on forwarding. Forwarders will ask 1) How do I know which > name to authenticate? and 2) How do I pass the result downstream? > There needs to be a simple, widely accepted answer to these questions > or SPF will fail. I was hoping we wouldn't be discussing this aspect of SPF quite yet. I believe we should first fix the DNS related problems (load, uncacheable macros, etc). Without these, forwarding policy does not matter, because the IETF will not allow a DNS-heavy SPF draft to become a standard. In that context, an unfocussed approach to fixing problems might just be a waste of time, if a standard is not possible. So I think we should put this one on the back burner, and come back to it after the -01 draft (which must include DNS fixes) is published. In this way, any DNS fixes can be readjusted (instead of introduced for the first time) at -02, along with the added forwarding policy. That said, when the time comes, I will propose a way to publish the local policy. What any secondary MX or forwarder wants to know is... "If I accept this piece for the recipient, will they accept it from me?" For secondary MX's this is a real problem, because currently all spam goes through there. The secondary MX cannot really do any kind of spam filtering for the primary MX. So my proposal will involve a *modifier* which can be checked by the secondary MX, and it will tell it what the primary MX would do. (ie, would it reject fails? Would it reject anything else? Would it accept "none" or "neutral" or even "pass" if it came through a secondary MX? Would it accept mail from the secondary if the sender is not already whitelisted? Will the primary MX reject the mail because the receipient was faked and does not exist?) The proposal will be along the lines of the l= modifier, which lists some rejection rules for secondary MX's or forwarders, along with a place to look for another SPF record that would be used as the "local policy" to use when mail is to be forwarded. Anyway, I have some ideas that I think are backwards compatible with SPF -01, but I don't think it's the right time to spend time on them now. They are very important additions, but it'd be best to introduced them in a planned manner. Regards, 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
|