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

Douglas Otis wrote:
> On Jul 1, 2009, at 7:20 AM, Alessandro Vesely wrote:
> > John Leslie wrote:
> > > The CSV paradigm is that the operator of a MTA should exercise some 
> > > responsibility for what is sends. The HELO string identifies the MTA 
> > > (though not necessarily one string exclusively by one MTA), and the 
> > > DNS management for that domain-name string states whether that domain 
> > > exercises responsibility (and by automatic return of A)ddress RRs on 
> > > SRV queries, what IP address(es) that MTA uses).
> > The link from the MTA to its operator is still missing.
> Disagree.  Based on our results, when only a few domains publish an IP 
> addresses of an Outbound MTA, it is rather safe to assume the domains 
> represented by verified EHLO information resolve who is administrating 
> the MTA.
In general an MTA provides a FQDN like mta.example.com, and we are 
unable to say whether it "is a member of" example.com. In addition, 
the MTA's administrator may be unrelated to example.com's registrant.
>  When there are many domains, this appears to represent either 
> MTAs operating behind a NAT, or compromised systems; sometimes both.
I don't understand that kind of setup. Multiple MTAs operating behind 
a NAT have no way to receive mail, so they are only sending SMTP 
clients. Is inertia the only reason why they don't use an MSA?
> It appears to be rare for legitimate Outbound MTAs to change domain 
> affiliations.  From a reputation standpoint, verified EHLO information 
> offers stable identifiers in which to effectively and efficiently manage 
> email abuse.
It seems that vanity domains don't mind if the MX record points to an 
MTA in another domain. The intricacies of having CNAMEs near MX 
settings presumably refrained also from assigning multiple names, one 
for each vanity domain, to a given MTA. However, some do it.
On an SMTP connection, a client says: "Hello mta.example.com", and 
after I accept that, it goes on with "Mail from:<xyz(_at_)example(_dot_)ORG>". 
What does that mean, in terms of accountability?
> > To this end, I'd prefer the use of a domain name.
This guy is relaying on behalf of someone else. If I had verified the 
"example.com" possibly registered domain, I would spot it more easily. 
If example.ORG is a vanity name, i.e. it has the same MX as 
example.com, I accept it. If not, I wouldn't know who is accountable 
for the message, so I reject it.
In case mta.example.com runs outbound MTA services for third parties, 
I would hold the originating third party accountable for the message. 
However, there is no way I can tell that is indeed the case, neither 
from the IP address nor from the name. I'd need, say, a CSA SRV record 
from example.ORG saying: "we authorize mta.example.com", _and_ on 
starting a new session the client shall say: "Hello on behalf of 
example.ORG: check their CSA settings". No guessing required, then.
> While larger ISPs are likely to have a few hundred outbound MTAs, they 
> represent a very small percentage of overall legitimate Outbound MTAs.
However, they transmit lots of messages.

> Being able to identify legitimate Outbound MTAs reduces the vetting of 
> hundreds of millions of domains associated with Mail From or PRAs, where 
> each domain likely covers massive address lists.
Exactly. Those legitimate Outbound MTAs are probably connected to an 
MSA. When we identify them, we enjoy the advantages deriving from 
users going through their relevant MSAs, as we recommended, rather 
than relaying through whatever MTA they have at hands, or directly.
> Efforts to combine the addresses used by a domain is counter productive 
> when it comes to resolving problems, or when dealing with initial SMTP 
> connections.  When it comes to SMTP, direct relationships involve less 
> overhead which improves efficacy and efficiency to the point of perhaps 
> permitting use of IPv6.
In some cases, names can be handled better than IP numbers. After all, 
that's why they invented the DNS...
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg