On Friday, February 10, 2012 08:26:49 PM Alessandro Vesely wrote: > On 10/Feb/12 16:43, Scott Kitterman wrote: > > On Friday, February 10, 2012 04:33:57 PM Alessandro Vesely wrote: > > ... > > > >>>> 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. > >> > >> If some leased addresses can get (soft)fail for ISP.example, the ISP > >> needs to scan outgoing SMTP transactions --if they are not cyphered-- > >> in order to avoid non-reportable cases. Otherwise a bot-master could > >> MAIL FROM:<[email protected]> from those addresses and get > >> away with it. > >> > >> (And that assuming that ISPs don't publish abuse-mailboxes for the > >> sole purpose of keeping admin and technical contacts clear of spam > >> complaints.) > > > > ... > > > > I think you are mixing things together that are separate. > > Sorry, I thought I depicted the case clearly... > > > I do think it's up to a network owner (such as an ISP) to police their > > IP > > space. If they don't want mail using their domain name to be sent out > > of > > their network except through their official MTAs, they can prevent that > > easily enough. > > No. ISP.example is a network provider, like softlayer.com leasing > 208.43.65.50 to controlledmail.com. MAIL FROM:<[email protected]> > sent from 208.43.65.50 (mailout03.controlledmail.com) would get a > softfail, if I'm not mistaken. Where should it be reported, if > abusive? ABUSE1025-ARIN tells [email protected], but one cannot use > it as target because of the softfail.
I think I haven't been clear (and maybe the text needs more work), but this is reasonable. Where I would object is if you wanted to send the report to [email protected] because they were used in mail from. > > The problem though is it's difficult to reliable separate this case from > > generic SPF non-pass conditions, so I don't think we should create a > > space for an unreliable solution to a problem that network operators > > can solve on their own if they care to. > > Agreed, but the more difficult the solution, the less likely they'll > be to take care. We could say that, given their SPF record, their > abuse POC should have been [email protected], but... This is where I think you've confused things. The relevant SPF check here would be on the domain you are sending the report from. It's got nothing to do with their SPF record or status of messages sent mail from their domain. > > None of this has any impact on the SPF status of the postmaster inbox. > > The message we are discussing here that didn't pass SPF was the > > original one believed to be abusive. > > Yes > > > That's got no bearing on the SPF status of any report to > > postmaster@. That's completely separate. > > It /was/ completely separated. Since -08 it triggers a SHOULD NOT. No it doesn't. Even if it does, it's got nothing to do with if SPF not-pass messages are accepted by their postmaster. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
