Alessandro Vesely <[email protected]> wrote:
>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.) This would only be relevant for their own domain, some other domain would be a different case. What I suggest isn't nearly so broad as you infer. >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. I don't agree. I don't see such a requirement. >>> 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. I think the DKIM pass with the same domain is a reasonable case. I can imagine a rouge ESP scenario where notifying the domain owner is a good idea. Thanks. I'll go back and modify my answer to Murray. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
