Why Do Email Admins Make Viruses Worse? 126
gripdamage asks: "Why are email administrators still sending virus bounce messages, when everyone knows viruses forge the sender? This effectively doubles the amount of email traffic due to the virus (triples in the case that the recipient is also notified). As one of the links says 'any AV software or admins that have it mis-configured [so] that it is continuing to send out notices...to forged senders, deserve to be ridiculed.' I have received 4 times as many erroneous bounce notifications, because of MyDoom , than the actual virus, so the bounce messages are much more of a problem! This is a problem deserving publicity, so that email admins will be shamed into doing the right thing." The problem is that most bounces are automated responses, the simple thing would be to turn them off. Of course, the rational of the automated response is to hopefully notify the infected user of the problem -- what a catch-22! What kind of policy would you recommend when it comes to spam, e-mail and automated responders?
It doesn't seem to be the admin themselves (Score:3, Interesting)
(fp!)
Re:It doesn't seem to be the admin themselves (Score:3, Funny)
Re:It doesn't seem to be the admin themselves (Score:2)
bounces are good (Score:2, Informative)
Re:bounces are good (Score:1)
Re:bounces are good (Score:4, Interesting)
I don't administer any of these programs, but I imagine they all do have the ability not to send these messages, but someone's got to change the settings.
Re:bounces are good (Score:2)
Re:bounces are good (Score:2, Insightful)
I run a mail server with 13000 users! Getting every bounce of these things to postmaster no matter who sent it would make me route postmaster to
Re:bounces are good (Score:2)
Re:bounces are good (Score:2)
Re:bounces are good (Score:1)
> postmaster no matter who sent it would make me route postmaster to
Dude, why don't you just route the "Warning: someone forging your address in
the From field sent us a virus!" messages to
Re:bounces are good (Score:1)
Re:bounces are good (Score:2)
Re:bounces are good (Score:1)
Check for valid source before notification (Score:3, Informative)
Re:Check for valid source before notification (Score:4, Informative)
An easy example: mail forwarders. Lots of places like you@alumni.your.edu forward mail to your "real" account.
Now let's say your ISP starts enforcing SPF. Your friend at AOL sends a message to you@alumni.your.edu which gets forwarded to you@yourisp.com. Your ISP's server notes that this message from someone at aol.com is being sent from a server other than one listed in AOL's spf list and rejects it.
People have suggested workarounds like sender rewriting but each of those suggestions breaks something else. You really don't want to see all the problems it causes for mailing lists.
For now, I'd settle for enforcing strict compliance with RFCs and good practice (helo must be a FQDN that can be forward and reverse dns matched with the connecting IP would be an excellent start - I can't believe how many large corporations can't get this one right).
Re:Check for valid source before notification (Score:4, Interesting)
I think that's what the submitter is complaining about. Anti-virus solutions sending bounce messages for virus infected emails to the people in the "from".
Re:Check for valid source before notification (Score:2)
I know a fair number of people disagree with me, but I'm willing to deal with the fallout of SPF - it doesn't break anything I care about that can't be fixed.
If enough people agree with me, it'll end up being the defacto standard.
Re:Check for valid source before notification (Score:2, Interesting)
Indeed. I'd pay money to get my ISP to block messages that don't have a
valid Subject: header.
> helo must be a FQDN that can be forward and reverse dns matched with the
> connecting IP would be an excellent start
I've considered merely rejecting mail from sending servers whose IP address
has no PTR record whatsoever. The only problem with this is that it blocks
approximately 110% of the continent of Asia from sending you mail. (Then
aga
Re:Check for valid source before notification (Score:1)
I thought SPF looked at the envelope From (i.e., the address in the Return-Path header), not the From: header in the message text. In your example the forwarded message would be coming From alumni.your.edu and would presumably be sent from one of your.edu's SPF-registered servers. Having SPF rely on the easily-forgeable From: header wouldn't make much sense.
Don't read this as an endorsement of SPF. I'm still trying to think through all the implications of such a system. But I don't think this line of c
Re:Check for valid source before notification (Score:2)
Let's say I was running a smarthost, the poster would want me to have it set to say
helo cpe-66-75-113-150.socal.rr.com
rather than helo peanutbutter.ruka.org, or helo there, or whatever stupidity my mta could think of
Bounce the headers (Score:4, Insightful)
Re:Bounce the headers (Score:3, Insightful)
I'd actually prefer if you bounced the entire attachment. In the case of virus outbreaks, it's a lot easier to filter out the unwanted bounces based on an attachment, than having to read all the headers and wonder if I (or a user) sent an email to someone with a subject line of "Hi".
Yes, it wastes bandwidth. But it saves human time. If you're that concerned about bandwidth, don't bounce known-spoofed-From:-header
Re:Bounce the headers (Score:1)
Re:Bounce the headers (Score:4, Insightful)
People using AV scanners need to hook them up to their SMTP servers so the SMTP server can reject the message as it is being sent. That way innocent people won't see a deluge of misdirected bounce messages.
Re:Bounce the headers (Score:2)
Re:Bounce the headers (Score:1)
It probably slows down the SMTP server a bit, but is that really so bad? It effectively limits the throughput of the mail server, should anyone on campus decide to send out a huge number of me
Re:Bounce the headers (Score:2)
If the virus scanner is overloaded, it's going to be slow getting the mail through the system anyhow, why hide the latency from the external servers?
(Yes, you could argue, what if the external servers end up not getting back to you, or losing the message, but I'd rather let the other server handle the bounce, so it's not on my hands)
Re:Bounce the headers (Score:1, Interesting)
That's great. I recieved thousands* of emails telling me that I was infected with the last MS virus. I run Linux. I don't particularly care about the bandwidth, I *do* care about the fact that my inbox was rendered useless for quite a while with all the anti-virus spam.
* (When I say thousands, the actual figure was twenty thousand over three months).
Re:Bounce the headers (Score:2)
Not exactly (Score:2, Insightful)
I agree that the bounces are damaging, but they usually don't multiply the damage; assuming one bounce per virus email, that is only 1x as harmful as the virus itself.
Most AV will not bounce the emails (these are the ones you don't see of course), reducing the ratio of (bounced emails) / (total emails) to below 1.
Re:Not exactly (Score:1)
Re:Not exactly (Score:1)
Re:Not exactly (Score:2)
Actually, the bounces are much more harmful to me than the virus. The virus is totally harmless to me, because I don't run Windows and just filter anything with a Windows-executable attachment to
The simplest rule I would enforce. (Score:3, Insightful)
I am fucking tired of seeing mail bounced to my server and email address, just because my email address (or domain) was in the From: portion of the message. They should be smart enough to take a look at the envelope portion of the header and see there is a difference.
Also, stop notifying senders that "you may have a virus". At all. If you want to do this for your own users, that's fine - but stop sending this shit to people outside of your domain!
And third... GAH... Where to begin. I give up.
Re:The simplest rule I would enforce. (Score:2)
In my opinion, the very best thing is to do scanning at SMTP-time. This is very easy with Exim (with the exiscan-acl patch) and clamav, both 100% GPL. By scanning during the DATA phase of message delivery, you can reply with a
It's not accidental, it's spam (Score:5, Interesting)
But this doesn't serve their purposes. Their goal, in the event of a virus outbreak, is to advertise. When people are getting viruses, they start looking for AV software, and that's the perfect advertising opportunity.
I always write back to the postmaster@domain to complain that their software is advertising, and I include a Cc: to the AV vendor, so they can see the negative publicity that results. It might help if everyone else did the same....
Re:It's not accidental, it's spam (Score:2)
Interesting.
As an worker bee I've been more in the camp of people who think
but I always forget the intended audience these advertisements target; higher management with spending decision authority and little direct experience in today's trenches.
Of course, that always to leads to the inevitable awkward Dilbert moment:
Re:It's not accidental, it's spam (Score:2)
I could not agree more (I'd mod you up, but you're already at 5). I also attribute it to admins trying to prove how cool they were (more is better, when it comes to output). But most of these admins probably don't no how to configure the settings to supress the message, so I think your explanation makes more sense.
Very Disturbing... (Score:3, Funny)
Re:Very Disturbing... (Score:2)
I'm bothered to by this too. Make sure that when you email everyone, you add a link to SCO's website so even if they don't get MyDoom they can help^H^H^H^H be aware of what is this virus all about.
It's an advertisement (Score:4, Interesting)
It's an advertisement, pure and simple. It's entirely to the software manufacturer's benefit to take the opportunity to advertise to third parties with you as the middleman.
And it works. I've had grey haired suits forward bounce messages to me to ask about the other products, asking whether we might want that instead of or in addition to the package I'd already put in place for them.
Report their virus bounce as spam!! (Score:2)
Re:Report their virus bounce as spam!! (Score:4, Interesting)
It's great that you are taking this political stand and sticking it to the virus scanner companies. I'm sure all the email admins out there make the logical jump that their virus scanner messages are causing their IP addresses to show up in RBL's. They'll all disable their virus bounce messages for you.
Actually, now that I think about it, it's more likely that people will assume RBL's are useless and don't work. They'll probably complain to their peers and convince them that RBL's are unreliable.
Way to go, jerk.
Re:Report their virus bounce as spam!! (Score:1)
Re:Report their virus bounce as spam!! (Score:2)
Re:Report their virus bounce as spam!! (Score:2)
Umm.. Razor, Pyzor and DCC are all programs that create spam SIGNATURES, not RBLs. Reporting a spam virus email to an RBL would be pretty stupid, but that's not what this guy did. Think before you post.
It's a subtle form of spam.. (Score:5, Insightful)
AV vendors know damn well that 99% of viruses spoof addresses. More than anyone else, since studying viruses and figuring out what they do is their JOB!!
The only possible excuse for this behaviour is that they get FREE ADVERTISING out of it. It's spam advertising AV software and/or mail filters, plain and simple. It should be treated the same way as any other spam.
Re:It's a subtle form of spam.. (Score:1)
Re:It's a subtle form of spam.. (Score:2)
Re:It's a subtle form of spam.. (Score:2)
Re:It's a subtle form of spam.. (Score:1)
If the company you worked for began to advertise its own products in unsolicited bulk e-mail, would you quit?
Re:It's a subtle form of spam.. (Score:1)
Re:It's a subtle form of spam.. (Score:2)
Re:It's a subtle form of spam.. (Score:2)
The idiot MSCE and/or PHB? Yes, absolutely.
Is there any difference between running 'spammy' AV software and hosting viagra-marketing spammers? If there is any difference I would think that the site running spammy AV software is more at fault, not less.
Problem is (Score:2, Insightful)
Many admins think that they are lord of the castle, if you suggest a change to the email system, like cancelling the bounce, the first answer is NO like you are stepping in their territory.
I used to work for a place where the admin also got so paranoid with spam that he blocked entire domains like yahoo and hotmail even though there were at least a dozen legitimate customers that used those email services as their primary business email.
It isnt until there is a backlash or fear of losing their castle tha
Re: (Score:1)
Accept and remove, or bounce? (Score:2)
If an admin were to bounce it then the only way to take care of it *correctly* would be to parse the header and send it to the ISP of the luser who is infected. They will (hopefully) notify the owner of the affected machine, and THAT user gets to fix their machine. Or, they can boost the economy a little and hire someone to do it or go buy some AV software.
Now a better way in my opinion would be to blackhole all emails re
third option (Score:2)
Yes, ye olde bit bucket - silent but deadly. Virus-infected emails check in, but they don't check out (or get delivered). Saves disk space, too.
Re:Accept and remove, or bounce? (Score:1)
There's no reason to do either. Just drop it into the bit bucket. You don't
save any bandwidth by rejecting it, since by the time you've detected the
virus you have already incurred the bandwidth burden. So just route it
direct to the dustbin.
Dumb AV software (Score:2)
I hate being forced into supposed "up"grades.
--Mike--
Re:Dumb AV software (Score:1)
What about CLEAN bounces? (Score:2)
Re:What about CLEAN bounces? (Score:2)
Re:What about CLEAN bounces? (Score:2)
Re:What about CLEAN bounces? (Score:2)
Re:What about CLEAN bounces? (Score:2, Informative)
The only acceptable way to generate a bounce of a virus message is as part of the SMTP dialog. That way the sending *server* will get the message, and it won't bother me.
While you go off and re-think your proposal, I'll just head over here and delete the last hundred or so of those cleaned bounce saying hey douchebad, you're infected.
we just bounce the headers (Score:2, Informative)
1) Messages which are obvious worms are not bounced at all, just dropped. This requires us to update the list of which AV hits are worms and which are just attachments in an otherwise legit mail. Obviously this isn't always kept up to date, but when a worm is wide-spread we make sure it isn't generating bounces. The bounces clog up the queue anyway.
2) Other messages are bounced, but only text portions
Re:we just bounce the headers (Score:1)
That's because you're only bouncing the text parts. I don't mind that quite
so much (though it still annoys me, getting hundreds of bounces for messages
that I didn't send, just because a bunch of idiots who think it's a good
idea to use Outlook have me in their address book). The real problem is
the AV packages that bounce the entire message, including the attachment.
That adds up to quite a lot of bandwidth. During the last big Outlook virus
outbreak I found that m
What's the to do with spam and viruses at the ISP? (Score:2, Insightful)
And don't ever send a bounce.
Send bounces only for mails not detected as either virus spam.
That would make everybody happy.
Re:What's the to do with spam and viruses at the I (Score:2, Insightful)
My pet peeve (Score:1)
Amavis (running clamav) has an option in there to specify which virii should be dropped instead of replied to, although it's manual so until you know how your virus software will ID things you'll probably dump replies. Maybe it'd be handy for AV database maintainers to add a flag, like a 'from header spoofer, please don't reply or you'll just make things worse' boolean.
good idea, (Score:2)
that about av database to have a flag for replying
Bouncing viruses (Score:5, Interesting)
Re:Bouncing viruses (Score:2)
Calling it spam is a little harsh, but these messages are definitely unnecessary and annoying, especially considering many viruses nowdays forge their sender addre
Drop bounces based on SMTP id (Score:2)
Re:Drop bounces based on SMTP id (Score:2)
Re:Drop bounces based on SMTP id (Score:2)
My suggestion is to aim for 90% coverage by watching for the formats from the half dozen biggest vendors, after all, the goal is just to put a damper on the secondary
Re:Drop bounces based on SMTP id (Score:2)
It doesn't cause any problems at all. If you thought it did then you would have listed them instead of being vague.
Receiving and sending SMTP servers are not necessarily the same machine
If you don't know that different machines can access the same database then you don't know enough about networking to comment in this forum.
Re:Drop bounces based on SMTP id (Score:1)
Re:Drop bounces based on SMTP id (Score:2)
This is from RFC822:
4.3.1. RETURN-PATH
This field is added by the final transport system that
delivers the message to its recipient. The field is intended
to contain definitive information about the address and route
back to the message's originator.
Note: The "Reply-To"
Re:Drop bounces based on SMTP id (Score:2)
Re:Drop bounces based on SMTP id (Score:2)
This is from RFC822:
4.3.1. RETURN-PATH
Ah yes! And we know all those virus writers strictly adhere to RFC822.
Spam filters anyone? (Score:1)
Another question: why not filter? (Score:2)
I know it would be expensive, that it would require people to do more work and buy more servers. But I don't see any other way of shutting down these mail virus storms.
This virus doesn't exploit any real holes. It depends on unsophisticated users doing something dumb. I don't think we're ever going to live in a world in which it won't be possible to trick unsophisticated users into doing something dumb. Does that mean we have to suffer through this
"Simple" solution? (Score:4, Interesting)
Next, is what to do after you've tossed the mail: to notify or not to notify. Well, I'm the type that believes that *someone* should get a notification if an email is tossed (ie, mail should never disappear without some sort of DSN going somewhere). So in the case of non-mass-mailing viruses, I send a notice back to the sender telling them their mail was canned, and why.
So my question to other mail admins (which I recently posed to the amavis-new list), is why not rely on the virus scanner's naming schemes? I use f-prot here, and all viruses that fake sender email addresses end with "@mm" (for Mass-Mailer). So I told amavis to not notify the sender if the virus name contains "@mm", but to notify the sender if it does not.
Result? I've blocked over 8000 copies of Mydoom in the last 24 hours, and not sent a single mail to the "sender"s, but when one of the professors sent a mail out with a Word document attached that had a macro virus in it, he got a mail back saying the message was stopped and why.
Simple, elegant... but why don't others do similar setups?
Re:"Simple" solution? (Score:1)
--
lds
Re:"Simple" solution? (Score:3, Insightful)
Laziness.
Can't just black-hole every sus email. (Score:2)
Re:Can't just black-hole every sus email. (Score:2)
FWIW, Symantec Mail Gateway Anti-virus (that's not the proper name, but you get the idea) can be configured in this way. Most mail s
Re:Can't just black-hole every sus email. (Score:2)
This still means that attachments rejected in the hours before the virus pattern arrives will get a bounce message, but they'll dry up as soon as the pattern's in place. Nicer.
Silent Failure (Score:2)
I send emails to some companies, they block all sorts of files. I tried to send a zip file that the customer, which was blocked.
I immediately got a message refused notice.
This allowed me to inform the customer that they would not get what I was trying to send, and we made alternate arrangements.
If they didn't send out the failure my customer would have been screwed, and I wouldn't have even known. When stuff doesn't happen in business you get blame
Re:Silent Failure (Score:2)
Known, suspected, and from isn't always wrong (Score:2)
Secondly only sometimes is the from false.
Someone might actually send the virus to someone else an email asking "What is this file you sent me".
For me silent failure is broken.
I have many times sent someone an email that they needed, only to find out it isn't getting through due to any of a multitude of reasons.
The worst is when their mailserver, which they don't control, blindly chucks email for stupid wrong reasons.
Re:Known, suspected, and from isn't always wrong (Score:2)
It's not rocket science to figure out how a new worm works. They know that they fake the senders.
That's not the same as a message sent by the worm, and should not be detected as such. The software should not just look at the attachment, but at the whole email. The real worm email would not include that question.
Re:Silent Failure (Score:2)
The problem is that if somebody sends an executable file, they need to know its not going to be delivered. So it bounces.
That creates the problem the article poster is complianing about, but I'm not really sure which is worse. The last thing I want is somebody thinking an email got delivered when it actually d
Re:Silent Failure (Score:2)
Yes. I agree. Notify the sender.
However, just because my address is in the from: field, that doesn't mean that I'm the sender, so don't notify me.
Good luck in finding the sender, though.
Username/Password (Score:1)
Disclaimer: I also work for them, so it makes my job as a first-line phone jockey easy to track down internal spammers.
What Not to Do (Score:1)
During the last Sobig outbreak, I recieved over 100 bounces per day from a single ISP in New Zealand. I e-mailed them to stop, pointing out that Sobig forged its "From" header.
They apologized and informed me I wouldn't receive any more bounces -- because their servers would now silenty delete all e-mail from my account.
I wanted to write back and point out that (a) this didn't help all the other people they were bouncing Sobig too, and (b) I might actually want to e-mail someone using them as an ISP one da
AV Auto-reply is the work of Satan (Score:2)