On 09/Feb/12 22:08, Scott Kitterman wrote: > 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. >> >> 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. An >> ISP's customer sends spam with MAIL FROM:<[email protected]>. > > There's no reliable way to distinguish that scenario from regular > spoofing, so it's pointless to use to drive design.
Except that we'd be providing a recipe for building non-reportable forgeries. > ISP can police his own network without external help, so it's not a > useful distinction in any case. The amount of support that ISPs may want to give to abuse reporting is unknown at this time. Requiring them to proactively policing abusive use of domain names in outgoing mail is probably not an option, also because that might interfere with contractual habits (more than explicit complaints from third parties.) Advice that abuse-mailboxes shouldn't be spam-filtered is spread throughout several papers. That the domain part of abuse-mailboxes should not be SPF-protected would be a new, somewhat obscure requirement, that is not going to improve SPF adoption. >> 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? > > It's a little more complicated than that and I think the suggested > text navigates the complexity correctly. We mention how to derive a destination address from * WHOIS, * rDNS, and * "pass" for SPF/DKIM domain. Any other destination is dicey, and SHOULD NOT be used. IOW, an address derived from WHOIS, rDNS, or DKIM does not need to be doubly checked against SPF none/neutral. And let me stress this once more: we are talking _only_ of addresses derived in one of those three ways. Yes, it is more complicated. For example, if I get DKIM pass and SPF fail for the same domain, I should hypothesize a replay attack which might be better reported as an authentication failure. But that's well beyond what this I-D is going to specify/state. _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
