Why on earth would Verizon need to do the lookup once per
incoming email? If they need to verify that a given MX
does indeed exist and is reachable and is running an
SMTP server, then why not cache that info for some
Er.. they are not looking for "MX exists". If MX and A didn't exist or were bogus (pointing at rfc1918 space or the loopback IP for instance) the mail could be rejected without going through all this song and dance about SMTP callbacks.
Consider a domain like (say) email.com <- that's one of ours, btw, that is extensively forged into spam.
What they are trying to do is to connect back to email.com's MXs and ensure that the user <sgswretyshsdhtest@email.com> who is trying to send them mail really does exist, and is not just a figment of some spambot's imagination.
It does tend to cut down on the amount of spam, but fails in several ways which have been discussed upthread (the most common being: the MX has an smtpd listener with no view of the userdb, like a cisco pix appliance with "smtp fixup", or a qmail smtpd instance). It is also a major headache for the operators of other mailserver clusters, especially the operators who host domains that are extensively forged into spam.
SMTP verification callbacks are a major nuisance, over and above the usual flood of forged spam. And it can set off all kinds of alarms when a NOC tech finds the same address (say imail@verizon.net) sending out thousands of emails to a whole lot of unknown addresses on your system.
Said tech went ahead and blocked that address. By the time I could investigate, Verizon was rejecting a bunch of valid mail as well ... their sender verify process was failing because our NOC tech had blocked the address they used for verification. [Beats me why they don't use something like verify@security.verizon.net]
reasonable time period, say an hour, to avoid disrupting
everyone else's Internet. Coupled with that caching, they
They could cache information about that particular envelope sender, sure.
But spammers send with extensively randomized and bogus addresses in the same spam run, so even that caching doesn't really help.
And if they are going to do something like this which
imposes a requirement on other ISPs, i.e. your MX
must point to a live SMTP server, and which impacts
That it must. No argument about that.
other ISP's mail operations, i.e. we will send you
An ISP whose domain's MX points to a dead or nonexistent server would notice a severe impact on their mail operations, I assure you.
450s, then why can't they *PUBLISH* what they are
doing. NANOG seems an appropriate place for this.
Glad somebody realizes this.
NANOG, according to the list FAQ, is not really the place to discuss spam, particularly as spam is not an operational problem.
The reason that I disagree with this line of reasoning is that spam is just as much of an operational problem as some other topics that are considered fit for discussion here (or at any rate, are regularly discussed here). Especially as most if not all spam these days has a network security angle to it (trojans, compromised machines, hijacked /16s ...)
Of course, most other operators meetings have whole conference tracks and tutorials on spam... in fact nanog seems to have had at least one or two of them in the past (with Paul Vixie speaking about spam).
Yes, lists like spam-l and spamtools exist (and so do several other lists, some of them semi-secret and by invitation only, even). But
* Quite a few nanog people don't read those
* Quite a few issues are often better discussed in the focused and clued atmosphere of nanog than in the tower of babel (aka news.admin.net-abuse.email)
--srs
