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

[Douglas Otis <[e-mail]>]

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