ietf-asrg
[Top] [All Lists]

Re: [Asrg] What are the IPs that sends mail for a domain?

2009-07-01 15:15:26

On Jul 1, 2009, at 3:17 AM, Ian Eiloart wrote:

The point of SPF is to authenticate the sending domain.

SPF(email-address)->pass provides authorization for Outbound MTAs. The rationale for offering SPF authorization might be to improve message acceptance or DSN rates, as recommended by AOL and MSN for example. It would be risky to conclude SPF(email-address)->pass means other domains did not provide assess to the originator of the message. It is fundamentally wrong to hold the wrong entity accountable.

If the IP address is authorised (by the domain owner) to send mail from the sender domain, then bouncing mail into that domain isn't going to be causing backscatter, unless the domain lacks internal controls over message submission. If it does lack those internal controls, then the users of the domain can blame the domain owner.

SPF(email-address)->fail might only indicate a message had been forwarded. Use of RFC 3464 and minimal DSN content with"multipart/ report" content types should occur irrespective of the SPF results when messages are returned post acceptance. Nor should one assume SPF authorization fairly assigns blame for poor administration of Outbound MTAs. How many ESPs even offer SLAs that ensure domain exclusivity when handling tens of thousands of domains?

I guess there can also be issues where two distinct domains share the same outbound IP addresses, through an email service provider. In that case, the email service provider is the responsible party that needs to be held to account. They need to ensure either (a) separation of domains by outbound IP address combined with accurate SPF records, or (b) proper implementation of MSA on all the domains that they provide service for.

Use of verified EHLO IP address information should only be claimed by a _few_ domains over a period of time. Seeing too many likely indicates the presence of a NAT, compromised systems, or both. The domain providing stewardship over access to Outbound MTA should be assessed separately from domains that have purportedly originated the messages. Even a cryptographically strong scheme like DKIM will not mitigate replay abuse, while it does help mitigate phishing. On the other hand, SPF might enable convincing phish whenever SPF(email- address)->pass is assumed to authenticate domain sources. It does not!

Backscatter is a problem, but bounce messages do have advantages over 5xx error codes when it comes to communicating with the sender. For example, you can't know what the sending MTA is going to do with a 5xx error code - they might just drop it. DSNs were invented for a reason, and it's a shame to lose them entirely - even when you have reason to believe that the return-path (or at least the return-path domain) isn't forged.

Best practices should reduce DSNs, often by ensuring immediate rejection is enabled where possible. Many of the DSNs from legitimate Inbound MTAs occur as a result of valid users not being known by border MTAs. Those appear to be mostly from poorly integrated hybrid systems protecting an Exchange Server or offering stand-alone inbound filtering services.

-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>