Alessandro Vesely <[email protected]> wrote:
>On 09/Feb/12 06:54, Scott Kitterman wrote: >> >> I think this is a MUST NOT. All it will lead to is pain. >> >> I will confess it's possible that I'm overly cynical about the >> ability of giving serious thought reliably producing the correct >> result here, but I really think that for whatever corner case that >> may exist, there's globally more harm associated with given people >> a free pass to think it over. > >A corner case: an ISP configure SPF according to their own mail >traffic, e.g. "v=spf1 mx:ISP.example ~all". The ISP don't trust their >customers enough to point WHOIS records directly to their >abuse-mailboxes, but does count-and-forward according to 8.10. Now, >an ISP's customer sends spam with MAIL FROM:<[email protected]>. The >abuse-mailbox resulting from WHOIS lookup of the source address is >[email protected]. That domain failed SPF authentication and thus, >you say, it cannot be the target of unsolicited complaints. Why? There's no reliable way to distinguish that scenario from regular spoofing, so it's pointless to use to drive design. ISP can police his own network without external help, so it's not a useful distinction in any case. >As for the whole idea, may I ask why softfail is considered less bad >than neutral? AFAIK people use them interchangeably when they don't >dare -all. SPF is opt-in, so I can't punish none results. The one receiver policy MUST in RFC 4408 is neutral MUST be treated the same as none. My proposed text is consistent with this. >We are already saying that the domain in MAIL FROM is likely a >reasonable candidate if SPF gave "pass". Doesn't that already mean >you should not use it if SPF gave any other result? Why do we need to >add that fail, softfail, temperror, and permerror, in particular, are >not good? > >Rather, I'd s/the domain that has been verified/the domain that has >been verified ("pass")/, in case that isn't clear enough. It's a little more complicated than that and I think the suggested text navigates the complexity correctly. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
