Re: incorrect spam setups cause spool messes on forwarders
Michael.Dillon@radianz.com 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 <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 -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
On Tue, 02 Dec 2003 19:23:41 +0800, Suresh Ramasubramanian <suresh@outblaze.com> said:
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.
And they tell that how, exactly, given that many sites do NOT allow VRFY or EXPN? I suppose they could do a MAIL FROM/RCPT TO pair, look at the result, and QUIT instead of DATA. Of course, that would be silly, because if it ever ran into another site that tried the same thing, that site would try to call back and do a MAIL FROM/RCPT TO...
Valdis.Kletnieks@vt.edu writes on 12/2/2003 9:32 AM:
On Tue, 02 Dec 2003 19:23:41 +0800, Suresh Ramasubramanian <suresh@outblaze.com> said:
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.
And they tell that how, exactly, given that many sites do NOT allow VRFY or EXPN?
MAIL FROM: RCPT TO: QUIT: is precisely what they are doing. Nobody except spammers / dictionary attackers seem to VRFY these days for this sort of stuff. In fact grepping your logs for VRFY is often a reliable sign of a dictionary attack on your machines.
I suppose they could do a MAIL FROM/RCPT TO pair, look at the result, and QUIT instead of DATA. Of course, that would be silly, because if it ever ran into another site that tried the same thing, that site would try to call back and do a MAIL FROM/RCPT TO...
MAIL FROM: <> typically, or from a sender that does not return callbacks to it ... so no danger of loops getting set up. Thank God for small mercies, I guess. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
On Tue, 02 Dec 2003 14:37 UTC Suresh Ramasubramanian <suresh@outblaze.com> wrote: | Nobody except spammers / dictionary attackers seem to VRFY these days | for this sort of stuff. In fact grepping your logs for VRFY is often | a reliable sign of a dictionary attack on your machines. VRFY is an (unavoidable) part of the checking routine built into the popular "Sam Spade for Windows" client, for manual verification of any suspect addresses found to have sent suspicious mail. So just looking for VRFY can give you some, er, false positives there ;-) and, as has been said, most sites don't allow it for obvious reasons. What is perhaps surprising, is the number of sites that disallow VRFY but leave EXPN fully operational ... | Thank God for small mercies, I guess. Implementing DELAY_CHECKS (which is normal anyway these days) will of course make a complete mockery of the process Verizon have implemented. -- Richard Cox
Richard Cox writes on 12/2/2003 9:57 AM:
VRFY is an (unavoidable) part of the checking routine built into the popular "Sam Spade for Windows" client, for manual verification of any suspect addresses found to have sent suspicious mail. So just looking for VRFY can give you some, er, false positives there ;-)
"a stream of vrfy / expn" I should have said.
Implementing DELAY_CHECKS (which is normal anyway these days) will of course make a complete mockery of the process Verizon have implemented.
Say again? All that delay_checks in sendmail (and this is the default in exim / postfix etc) does is to defer any rejects based on IP / sender domain etc till the RCPT TO stage instead of returning 5xx at MAIL FROM: itself. I don't see how or where this will have an impact on verizon's sender verify. cf/README for sendmail says -
delay_checks The rulesets check_mail and check_relay will not be called when a client connects or issues a MAIL command, respectively. Instead, those rulesets will be called by the check_rcpt ruleset; they will be skipped under certain circumstances. See "Delay all checks" in the anti-spam configuration control section. Note: this feature is incompatible to the versions in 8.10 and 8.11.
srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Hi, ...on Tue, Dec 02, 2003 at 07:23:41PM +0800, Suresh Ramasubramanian wrote:
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, [..] 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,
While sender address verification puts additional load on (more or less) innocent bystanders, it's right to exist is, as you said, based on the fact that it eases the spam load to the recipient - like many other intrusive anti-spam techniques. I agree that much of the anti-spam stuff out there is kludgy at best, and often harmful to other users, but let's not forget that it's the spammers who make all this necessary... At the edge of the net, where traffic can still be a major cost factor despite the limited bandwidth, having to transport 20% to 50% spam is a real burden that fuels many desperate decisions. If some of the large Email providers like Outblaze, Hotmail, Yahoo, AOL, etc. could agree on a more integrated approach to implement at least some form of sender authorization - possibly in the line of the RMX RR draft[1] - as a service to the public, the aggressive MX callbacks would perhaps be made redundant... While RMX and similar ideas certainly are no perfect solution, it's a cheap way to attach some trust level to a message, and gives the email providers the chance to solve the problem at their end as they gain control over the users of their domain name(s) by hampering unauthorized usage. Alex. [1] http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt -- AB54-RIPE
On Tue, 02 Dec 2003 20:05:47 +0100, Alexander Bochmann <bochmann@FreiNet.de> said:
I agree that much of the anti-spam stuff out there is kludgy at best, and often harmful to other users, but let's not forget that it's the spammers who make all this necessary...
Today's stupid spammer trick: The other day, I posted something in reply to Stephen Wilcox, with a cc: to this list. Less than 10 minutes later, I got 4 notes from a site saying that my posting (which still had nanog and wilcox referenced) had tripped a content sensitivity filter. Double checking my outbox, I'd only posted one thing that had both wilcox and nanog in the headers for at least a month. Despite all this, the site admin in question fished out the actual note from their quarantine, and discovered that it was spam for some enhancement product. The only conclusion we could come up with is that somebody on the NANOG list is infected with some sort of malware that waits for mail to arrive and then uses its headers to generate a joe-job spam, and that 4 spams had gone off to the site that generated the notes back to me. Forget the baseball bat, this one deserves a lead pipe... :)
Alexander Bochmann writes on 12/2/2003 2:05 PM:
If some of the large Email providers like Outblaze, Hotmail, Yahoo, AOL, etc. could agree on a more integrated approach to implement at least some form of sender authorization - possibly in the line of the RMX RR draft[1] - as a service to the public, the aggressive MX callbacks would perhaps be made redundant...
There are just too many RMX proposals around. Once some of them get consolidated, it will be a good idea to adopt the best and most popularly accepted one. At least now that ASRG has some good new leadership with John Levine stepping in as co-chair (Yakov has always been doing a great job) I hope things move forward :) By the way there will be a panel on the different proposals during the conference track on spam that we at apcauce.org are organizing at APRICOT 2004 (www.apricot2004.net). Speakers include Dave Crocker and Meng Weng Wong (the originator of spf) srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
participants (4)
-
Alexander Bochmann -
Richard Cox -
Suresh Ramasubramanian -
Valdis.Kletnieks＠vt.edu