Douglas Otis wrote: > Local-part expansion and the "exists" macros seem of > minimal utility for legitimate purposes.
The possible purposes are obvious, "per user" policies treating the local part as labels, and "exists" be a a way to get around the "check at the border" limitation for MAIL FROM, by definition HELO checks work everywhere. I'm still curious how minimal such uses are, and if they could be simply deprecated as nice try. On the border of legitimate is using "exists" for logging, receivers are likely not interested in this job. OTOH "exists" is not the only way to arrange logging. > What handling occurs for messages resulting in NEUTRAL? Specified with not less than a MUST is "like NONE". But what receivers in practise do is "receiver policy", they could decide that a Gmail NEUTRAL or a Paypal SOFTFAIL is bad. When they decide this it is their decision, no part of the protocol as specified. The same goes for a "best guess" approach for domains without published policy. Your MX idea, roughly "v=spf1 mx -all", is near to a best guess "v=spf1 a/24 mx/24 -all", but nobody would dare put this into a RFC for various good reasons. > NEUTRAL represents the same status "as if" no SPF > records exist. RFC 4408 says, yes. And receivers do what they like with it, as they could accept a FAIL instead of rejecting it, no matter how bad that can be, or discard SOFTFAIL, or treat a PASS from unknown strangers as spam on Tuesdays. They have some additional info to "get it right" in some cases like PASS or FAIL, but they are free to use this info or its NEUTRAL absence in other ways. If they are confused they could evaluate v=spf1 against Message-IDs or a PRA, and claim that the spam recognition rate is better than a random generator. They can't claim that they found this recipe in RFC 4408, like folks adopting a "discard them all" strategy cannot say that this is what 2821bis wants them to do. > Impediments inhibiting new resource record types weigh > heavily against promoting ubiquitous publication for yet > another optional SMTP feature. The spammers recruit new SPF publishers, anybody finding his inbox flooded with misdirected bounces is motivated to learn this within hours, not days. Fortunately the esoteric macro and "exists" features are unnecessary for ordinary my.domain.example users. > A mandate to publish MX records will not impact where > messages might originate as this does. However, the > mandate will impact where policy records such as SPF > or ADSP are to be found. Then I misunderstood your goal, are you "only" talking about "v=spf1 -all" for domains never sending any mail ? Some folks here volunteered to address this issue in an I-D after the debate to limit the A-fallback to IPv4 in 2821bis ended inconclusive. Solving it generally is anyway better, and hopefully a solution does not need "v=spf1 -all" or null-MX opt-out hacks, opt-in is so much better. > DKIM provides a means to identify sources Simplified DKIM is a "signed timestamp line" indicating some kind of responsibility. It's not about backscatter and not about delivery reports "to the originator of the undeliverable mail (as indicated by the reverse-path)" - that's what I thought this thread is about. Frank
