On 12/14/2017 03:28 PM, Brandon Long via mailop wrote:
My point is that -all is policy, and most people ignore the policy portions of SPF because it completely fails a lot of forwarding cases.
Every postmaster (or organization behind them) has the prerogative to run their mail server(s) the way that they want to.
That doesn't mean that the policy is any less a policy. It just means that people may not honor it.
Nor does the fact that receivers may not honor it mean that senders should not publish the policy that they want.
-all is asking receivers to reject mail that doesn't pass.
Yes.I, as a sender, have decided that I want receivers to reject messages that do not match my published policy. Period. End of story.
In practice, very few receivers implement SPF policy (except -all by itself for domains which don't send mail as a special case).
What sort of data / experience do you have to back that statement up? (I've not looked for any.)
Maybe there are some smaller receivers who will pay attention to it, but you're almost certainly going to get more false positives from them than real positives. And you won't even notice.
(Data?)
If you want policy, use DMARC, it's what it's there for, and these things are considered. As much as DMARC rightly gets pushback for the parts of forwarding it fails at, it's definitely more useful for policy goals, and has much wider adoption.
How does DMARC fail at forwarding? DMARC (SPF and / or DKIM) specify who is allowed to send email, including forwarding, on the purported sending domains behalf.
If I don't authorize anyone other than my MTA to send email (as short sighted as that may or may not be), then anyone else sending email claiming to be from me is blatantly unauthorized.
Do people forward messages? Do mailing lists redistribute messages? Sure.Did my server contact the ultimate recipients and deliver a message on my behalf in these cases? Absolutely not.
So is the message that was distributed purporting to be from me legitimate or not? - There's a lot of room for debate on that.
But it does not change the fact that SPF / DKIM / DMARC are designed to provide information and add validity to inform recipients who is authorized to send message and derive who is not. - What the receiver does with said information is at the receiving postmaster's (or their organization) discretion.
I feel like (a significant portion of) many discussions around SPF / DKIM / DMARC revolve around what I consider to be a priming issue. - People don't want to publish / filter a $Technology because not enough other people are filtering / publishing said $Technology.
I personally believe in SPF / DKIM / DMARC technologies enough that I both publish information and run filters based on the information that others publish. - I running my mail server for the world that I want, not the world that we have. - Hopefully, someday, the gray area between the two will get smaller.
DKIM, for example, explicitly says that a DKIM fail means nothing. Which doesn't prevent folks from rejecting messages with broken DKIM signatures, probably the same folks who follow
IMHO DKIM is to be considered a proof positive, that a message has not been modified. You can't prove the negative, that a message has been modified. - I believe that other cryptographic signatures are in a similar position. (I'm ignoring collisions for this discussion.)
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
