|
Re: [Asrg] What are the IPs that sends mail for a domain?
2009-07-03 12:52:22
On Jul 3, 2009, at 4:48 AM, Alessandro Vesely wrote:
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.
The goal is to establish stable and fair identifiers. Once a direct
DNS relationship with that of a host can be verified, this serves as a
identifier controlled by _some_ administrator. Verification of a DNS
relationship allows negative host stewardship assessments to be fairly
made based upon the identifier. A fair and stable identifier is being
sought. Not one that represents some person. Anonymous tokens help
avoid claims of individual censorship. The application of host
stewardship assessments can allow spam to be effectively and
efficaciously managed, and is how accountability can be established.
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.
Those with a DS3 serving their office network may expect they have an
ability to publicly send email to other domains.
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.
Dependence upon just the domain of MAIL commands or PRAs would be
vulnerable to exploitation. Assertions that authorizations offer
authentication are not safe. In addition, there are hundreds of
millions of MAIL command or PRA domains to be tracked, white there is
about two to three orders of magnitude fewer EHLO domains. A mistake
made with a MAIL command or PRA domain will create serious and
irreconcilable problems for the domain. A mistake made with a EHLO
host is both less likely, and will be far less catastrophic since
services elsewhere can be sought. In addition to being safer, more
accurate, EHLO assessments are more efficacious and effective. There
are fewer in which to deal with, and this instills a hierarchy of
management that better confronts rampant abuse largely caused by bot-
nets.
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.)
Those offering the service should still be assessed upon their
stewardship of who is allowed to send messages. When they fail to
remove problematic access to their Outbound MTAs, those MTA might
become blocked, and their customers will then need to seek service
elsewhere. When a MAIL command or PRA domains are blocked for
because authorization has been confused with authentication or when
spam is spoofing the domain, those affected are left without
recourse. Not wanting to track dramatically fewer EHLO host names
with that of a small number of IP addresses is poor justification for
a potentially injurious practice making guesses about MAIL commands or
PRA domains. :^(
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.
IMHO, systems used within private or authenticated exchanges is of no
concern. It is only the Outbound MTA sending messages to different
domains on port 25 without authentication that needs management.
Guesses about what might have occurred ahead of the Outbound MTA can
be injurious to otherwise innocent domains.
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.
Vouchers? Taking accountability? Logically extending that concept
should then involve significant liabilities for providers that fail to
ensure MAIL commands or PRAs are limited to their rightful owners.
What RFCs should these providers be following? How does one determine
who is the rightful owner, and have you ever seen such agreements, and
do you know which standards need to be followed? Is this assurance
expressed within your SLA with your provider? Does this agreement
specify exclusivity for use of MAIL commands or does it also include
PRAs? You are describing a fantasy that may cause injury when
believed. We need to hold parachute manufactures liable for their
product, and not those using parachutes.
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.
It only needs to lead to an identifier that can be fairly and safely
blocked while mitigating email abuse.
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.
The task of holding individuals accountable needs to be delegated to
the Outbound MTA providers. After all, these providers are being
compensated, and not their recipients. Expecting recipients to make
guesses about who the originators were overlooks the reality that
Outbound MTA provider granting access are the _only_ entities able to
make this determination. When they haven't or can't, they should be
blocked when abuse is being emitted.
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.
DKIM is to prevent spoofing. DKIM is not intended to serve as a means
to mitigate email abuse.
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.
This alternative for white-listing was mentioned only to suggest safer
methods that don't rely upon potentially hazardous scripts.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
|
|