Sabahattin Gucukoglu <mail(_at_)sabahattin-gucukoglu(_dot_)com> wrote:
I've got a message in my queue here destined for natwest.co.uk.
Natwest.co.uk exists, but it isn't running an SMTP service; it's intended
as a web server... The message is a DSN generated by this host.
These are common. Often it is a misconfiguration, more often it's a
forged MailFrom in a spam.
But, s/a message/a million messages/ -- you get a better idea of the
issue. If I didn't reject most spam at SMTP time, I'd probably have a
million of these critters in _my_ mail queues. Large ISPs probably have
a million, even _after_ rejecting what they can at SMTP time. :^(
There's no MX, and I don't check SPF.
Let's leave aside the religious arguments about SPF -- in at least
some cases, it does clearly indicate an intention to receive email
addressed to a domain. Can we agree that an MX record, when accurate
and up-to-date, _does_ indicate an intent to receive email?
If we have an indication of intent, it's reasonable to keep a message
like this in the queue. But what if we don't have such an indication?
Let's also leave aside the religious arguments about what belongs in
2821bis. (IMHO, this is largely an operational tuning issue, and the
protocol spec shouldn't try to mandate operational tuning.)
The original message was intended for a primary host for which I am
an acting secondary...
The same issues arise in many corporate environments where the
externally visible MX MTA has limited visibility to the actual MDA.
Which is the problem?
1. I am naive enough to receive mail from non-verifiable senders...
2. I am not doing enough to ensure that I will not have to generate
a DSN.
Both, to some degree.
Given the preponderance of spam, it is silly to argue that non-delivery
is rare. To return a 250 to the DATA phase without any checking whatsoever
of the bounce address _is_ naive unless you have matched MailFrom (e.g.
null) or RcptTo to a directive to _never_ send bounces.
(I decline to argue whether 2821bis "should" permit such rejection at
SMTP time: clearly some folks _will_ do so. Besides, blindly following
a spec _can_ be called "naive".)
OTOH, _anything_ one might do to determine that a message will not be
delivered is best done as early as possible. Most spam-abatement measures
produce the happiest results if done by the first MX MTA during the SMTP
session.
The problem is not the semantics of nonexistent senders so much as that
the result is backscatter and full mail queues.
Backscatter is a support nightmare. Unless you can match NDNs to actual
messages sent, many customers will be happiest if you discard them all.
Full mail queues is less of an issue (up to a few hundred thousand,
anyway). Those just slow things down...
My endeavours are better served by protecting the recipient mailboxes;
by guaranteeing that they are either deliverable or not at the SMTP
level (usually RCPT command).
Agreed.
My vote is for 2 on general grounds of practicality, ease of
implementation and least harm done. Perhaps elements of 1 can be added,
In general, more tools is better...
but I'm not certain it's at all useful unless it's done thoroughly enough.
While policy-wise 1 makes sense, yet there is little doubt it could never
become standardised.
It is a mistake to think we _could_ standardize sender verification.
There's a continuum, not a sharp knee. Individual administrators need to
balance the probability of successful delivery against the probability
of an NDN failing to reach a useful mailbox or process. Proposals like
BATV can raise the latter probability arbitrarily high; provable absence
of mail service can reduce it arbitrarily low; mostly we're stuck in the
middle.
What is upsetting to operators is a seemingly religious claim that
it's wrong to expect domains to actively signal their intent to receive
and process email. If they won't, we feel somewhat justified in rejecting
email likely to bounce before acknowledging the DATA phase. At some point
(long passed IMHO), calling us bad people won't be sufficient to stop
this.
The problem <ietf-smtp> can't seem to face is that the mere presence
of a process listening on port 25 of a particular IP address says nothing
about intent to receive email for a particular domain which has an
A)ddress record pointing to that IP address. An MX record _does_ state
such an intent. There _are_ other ways to state such an intent, BTW.
It would do too much harm,
That's a judgment call...
and the actual benefit is questionable when 2 is an option that has for
a long time been advocated as a best practice
... though not always possible...
(many small sites stopped using backup MXs just to avoid the
administration and many other sites are less willing to act as backups
for complete strangers).
Backup MX isn't the only use case (though we've mostly abandoned it).
There are good reasons in many environments to accept email "outside
the firewall" and forward it through the firewall to a server whose
status you cannot know. It's also common to have different spam
filtering for different accounts, at least some of which are "inside
the firewall. (One doesn't need to approve of "firewalls" to acknowledge
that such practices are common.)
We certainly could design a mechanism _better_ than MX records to
document intent relative to receiving email, especially DSNs. But unless
and until we do, folks are likely to use MX records as part of the
balancing act of guessing the probability of NDNs reaching a responsible
reader.
--
John Leslie <john(_at_)jlc(_dot_)net>