[EMAIL PROTECTED] wrote: > 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]) 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 [EMAIL PROTECTED] > 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 -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
