Sabahattin Gucukoglu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
