|
Re: [Asrg] What are the IPs that sends mail for a domain?
2009-07-03 07:48:39
Douglas Otis wrote:
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 the EHLO host name references IP addresses that match the Outbound
MTA, this verifies there is a common administration between the FQDN and
DNS. CSV ensures this relationship can be established [...]
That is not the case. The hostmasters at example.com can unilaterally
delegate mta.example.com the way they wish, with no obligation
whatsoever to run a whois service or otherwise publish data about
their delegate's admins, if any, let alone taking accountability for
what such admins would do.
Outbound MTAs can be unrelated to where their mail is received.
Even so, port 25 of the NAT can be nailed to a host within the NAT's
private address space. Outbound MTAs behind a NAT is fairly common in
office environments.
Yeah, I used to suggest that setting myself, since most of (legit)
mail traffic is intra-office. They may collect external mail running
cron-scheduled POP clients. However, with today's connections and
legit mail being a tiny fraction of mail traffic, I see no reason for
keeping those servers. I regard them as historical settings, and
recommend using SUBMIT+IMAP on secured channels.
With EHLO mta.example.com and a history of that host name [...]
From a reputation perspective, the name and IP address relationships
that need to be tracked for Outbound MTAs represent data sets orders of
magnitude smaller and dramatically more stable that that represented by
MAIL commands or PRAs.
However, one year after changing the IP address of my MTA, many MX
receivers are not yet up to date. I'll have to manually update that,
where possible, taking into account each domain idiosyncrasies. It is
so because those name-address relationships are still too many. If you
consider only the right hand side (RHS) of MAIL or PRAs, you'll get
much smaller figures.
In case mta.example.com runs outbound MTA services for third parties,
I would hold the originating third party accountable for the message.
Why not hold the entity offering access to those abusing email accountable?
If they just offer a transport service, I see no reason I should.
Vice-versa, if they are accountable, then _they_ are the true MTA,
transmitting on behalf of what I called a vanity domain. (This
distinction does not have to be static, as example.ORG may send
directly in some cases, via example.com in others.)
You have no assurance whether third-party domains originated the
message, even when the domain offers authorization. This assumes
Outbound MTAs ensure both the PRA and MAIL commands are restricted to
specific and verified users. While this might be the case, this is not
the norm.
OTOH, if we cannot spot whether an MSA has been used, the advantages
of clean transmission remain confined within the first hop. An MTA who
accepted to relay on behalf of an authenticated user may be willing to
take accountability. The point is that it has no verb to express that
will.
It would also be foolish to annotate email as having been
"authenticated" on the basis of Outbound MTA authorization for the same
reason. Large companies place a higher priority on their messages being
received than ensuring authorizations do not expose exploits to bad
actors.
If they take accountability, then it's their problem. Their vouchers
should take that behavior into account.
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.
Yes, the CSA record would help, but this EHLO information still offers
value. Especially when considering the use of IPv6 where block lists
are unlikely to prove effective.
I agree EHLO information has some value. In some cases, it may be
redundant (e.g. if there is a vouch, or in case of ideal DNS
settings.) In most cases, it is not enough, as it doesn't lead to an
accountable administrator's name, address, phone number, etc.
The issue is simpler than that. The issue is to simply
hold the Outbound MTA accountable for the message sources for whom it
grants access. DKIM offers a reliable means to verify where a message
originated without impractical and unscalable efforts aimed at
registering all authorized paths for MAIL commands or PRAs.
Both Outbound MTAs and DKIM offer no hint about a message's Originator
and related accountability issues.
For counting, note that the number of DKIM signers potentially exceeds
the number of valid RHS domain names, since each mail domain can be a
DKIM signer, but a DKIM signer doesn't have to be a mail domain.
DNS CIDR notation is specified by RFC 3123. This resource record can
still be used to establish email white-list strategies instead of SPF
records. APL records exclude potentially problematic macros as well.
Since email CIDR records should not be obtained in response to SMTP
connections, APL might be chained with a convention for _n._smtp APL, as
an alternative publishing location for _smtp APL. When _smtp is
truncated, either TCP fallback could be used, or _[0-9]._smtp APL
queries might be used to recover from response truncation.
However well designed, such scheme will thickens the ranks of mail
transmitter authentication schemes. All of them are optional, and
checking which one may apply requires an increasing amount of DNS
transactions, possibly amplified by DNSSEC. That's why VHLO, besides
taking the mail domain of the accountable organization, can also take
the parameters indicating which authentication method applies.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
|
|