Jump to content
Sign in to follow this  
CreationX

Automatic Virus Notification classified as SPAM

Recommended Posts

In response to a recent black-listing by SPAMCOP of our domain.

Background:

We currently use Sophos Antivirus to protect our PC's and email from known viruses. All email sent to our organisation is swept at the mail gateway for viruses. If an email containing a virus is detected the sender is notified with the following:

a) To re-send the email without the virus.

B) Check their machine for viruses. A link is provided to assist.

With the MyDoom WORM (and others like it) our email server has seen an increased amount of email traffic containing VIRUSES.

In response to an infected email our mail server has responded with the standard virus notification.

As a result our domain has been blacklisted by SPAMCOP.

The explanation and sample text provided by SPAMCOP clearly shows the Subject: "Virus Notification" for each and every one of the so-called spam email's.

The Answer, or is it?

The simple answer to this would be to disable the automatic virus notification.

This is something we have devoted a huge amount of discussion to over the past few days. We have decided against disabling the virus notifications for the following reasons:

a) Our links to emergency services such as Fire & Rescue, Police & Paramedics.

B) Confirmation / Courtesy a senders email was received therefore allowing them to re-send a virus free email.

c) With today’s society relying heavily on email it would be un-realistic of us to delete an email, received from another and not notify the sender.

d) The amount of traffic our IT helpdesk would receive in relation to 'lost' email would be unsustainable.

Whilst we should not 'rely' on email the truth is most of us do. As an IT Engineer and end-user support person I see this every day.

On a side note our organisation strongly supports the Anti-spam Message.

We would like to have our domain removed from the blacklist and an explanation from SPAMCOP as to what steps are being taken to resolve these incorrect listings.

I am keen to hear your thoughts on this topic. Has anyone experienced a similar incident? Do you think automatic virus notifications are spam? What can be done to stop incorrect black-listings of this type?

Share this post


Link to post
Share on other sites
In response to a recent black-listing by SPAMCOP of our domain.

Background:

We currently use Sophos Antivirus to protect our PC's and email from known viruses. All email sent to our organisation is swept at the mail gateway for viruses. If an email containing a virus is detected the sender is notified with the following:

a) To re-send the email without the virus.

B) Check their machine for viruses. A link is provided to assist.

With the MyDoom WORM (and others like it) our email server has seen an increased amount of email traffic containing VIRUSES.

In response to an infected email our mail server has responded with the standard virus notification.

As a result our domain has been blacklisted by SPAMCOP.

The explanation and sample text provided by SPAMCOP clearly shows the Subject: "Virus Notification" for each and every one of the so-called spam email's.

The Answer, or is it?

The simple answer to this would be to disable the automatic virus notification.

This is something we have devoted a huge amount of discussion to over the past few days. We have decided against disabling the virus notifications for the following reasons:

a) Our links to emergency services such as Fire & Rescue, Police & Paramedics.

B) Confirmation / Courtesy a senders email was received therefore allowing them to re-send a virus free email.

c) With today’s society relying heavily on email it would be un-realistic of us to delete an email, received from another and not notify the sender.

d) The amount of traffic our IT helpdesk would receive in relation to 'lost' email would be unsustainable.

Whilst we should not 'rely' on email the truth is most of us do. As an IT Engineer and end-user support person I see this every day.

On a side note our organisation strongly supports the Anti-spam Message.

We would like to have our domain removed from the blacklist and an explanation from SPAMCOP as to what steps are being taken to resolve these incorrect listings.

I am keen to hear your thoughts on this topic. Has anyone experienced a similar incident? Do you think automatic virus notifications are spam? What can be done to stop incorrect black-listings of this type?

The Anti Virus companies including Sophos post on their sites about the virus details and specifically say the "From" Address is forged but they still send the notification to the "From" address which is an innocent victim. And they advertise their software in the reply.

It is spam as you are knowingly spamming an innocent victim.

Think about it. No rocket science needed for this one.

Share this post


Link to post
Share on other sites

It is a violation of Spamcop terms of service for members to use it to report viruses, or misconfigured mail servers that should not be sending out virus notifications to innocent parties.

We currently use Sophos Antivirus to protect our PC's and email from known viruses. All email sent to our organisation is swept at the mail gateway for viruses. If an email containing a virus is detected the sender is notified with the following:

a) To re-send the email without the virus.

Check their machine for viruses. A link is provided to assist.

That is a very bad and abusive practice. Please stop spamming innocent victims with virus detected notices.

Almost all the viruses that are currently spread by e-mail forge the sender information, and the people you are spamming with the virus notices can do nothing to stop the viruses from being sent to you.

All you are doing by sending these notices is assisting the virus writers in their goal of clogging the internet e-mail system.

Virus notices should only come from the local postmaster or personal contact..

You should either use SMTP reject codes when you detect a virus, or send the notification to the Postmaster / abuse addresses for the I.P. that your mail server accepted the virus from. They are the only ones that can stop the viruses from being sent.

In many cases you are spamming mailing lists, which means that for each virus you detect, you have spammed hundreds if not thousands of innocent victims.

This is something we have devoted a huge amount of discussion to over the past few days. We have decided against disabling the virus notifications for the following reasons:

You should re-think your policy. Sending out these useless virus detected reports will cause content filters to be set to remove all virus detected notices.

And many mail servers that are being victimized by your abusive practices will stop accepting all e-mail from you.

a) Our links to emergency services such as Fire & Rescue, Police & Paramedics.

Confirmation / Courtesy a senders email was received therefore allowing them to re-send a virus free email.

Use SMTP reject codes or send the notificaiton to the POSTMASTER address that you accepted the e-mail from.

Do not ever send notifications to the forged addresses that the virus came from. You are not sending them to anyone that had anything to do with sending you the virus.

All you are doing is assisting the virus writer in making a mess of the internet e-mail system.

c) With today’s society relying heavily on email it would be un-realistic of us to delete an email, received from another and not notify the sender.

Your current practices are making it more likely that e-mail from your mail server is likely to be deleted unread.

E-mail has no guarantee of delivery or notifications of non-delivery. Anyone that is expecting reliable e-mail delivery will eventually have problems because of this.

Spamming innocent victims with virus notifications is abuse, and many spam filtering techniques will delete possilble spam with out notifying the sender or the receiver.

By knowingly sending virus notices to innocent victims, you are encouraging the users of those filters to silently delete all e-mail that comes from your domain.

d) The amount of traffic our IT helpdesk would receive in relation to 'lost' email would be unsustainable.

I and others encourage everyone that gets these abusive "virus detected" spam to send a manual report to the abuse desk. Do you want your help desk to receive several thousand abuse reports when a virus forges the from: address of a very large mailing list?

There are two reliable (as permitted by SMTP) ways to notifiy someone of non-delivery.

1. Reject the mail with SMTP codes.

2. Send a rejection mail to the postmaster address for the I.P. address you received the undeliverable e-mail or bad content from.

Generating a bounce to the alleged sender is more likely to spam an innocent victim than it is to reach someone that actually sent the mail or can control it's sending.

While it used to be a courtesy to send such notifications, using anything other than SMTP rejects or notiications to the postmaster address is now abusive, and when spammers find out your mail server is doing it, they may target it to bounce even more spam around blocking lists.

-John

Personal Opinion Only

Share this post


Link to post
Share on other sites
In response to a recent black-listing by SPAMCOP of our domain.

...

If an email containing a virus is detected the sender is notified with the following:

a) To re-send the email without the virus.

B) Check their machine for viruses. A link is provided to assist.

We have decided against disabling the virus notifications for the following reasons:

a) Our links to emergency services such as Fire & Rescue, Police & Paramedics.

B) Confirmation / Courtesy a senders email was received therefore allowing them to re-send a virus free email.

c) With today’s society relying heavily on email it would be un-realistic of us to delete an email, received from another and not notify the sender.

d) The amount of traffic our IT helpdesk would receive in relation to 'lost' email would be unsustainable.

...

We would like to have our domain removed from the blacklist and an explanation from SPAMCOP as to what steps are being taken to resolve these incorrect listings.

Your reasons for sending the notifications are fine, but they're not well applied.

If a person sends you an email, and they attach a virus-infected file, then it's desirable (necessary, even) to send them a message back when you block their message. If the email is generated by a virus which uses the sender's real address, then there is also a case for sending a message back.

If the email was generated by a worm which forges sender addresses, then there's no value in generating a bounce message - all you are doing is spamming third parties, and the infected person won't get to know about it.

The problem you have, I assume, is that your Antivirus software, like most mail server AV software, isn't clever enough to let you send messages back only when they are desirable.

Given that 99% of the stuff it catches is likely to be one of the recent email worms, I'd be inclined to go for the option of turning the bounces off. For the server I run, no bounce is sent, but the admin gets a notification. It's easy to spot any blocked emails which aren't MyDoom or whatever the latest worm is, and sort out those cases by hand.

Having said all that, Spamcop's list policy is not to include servers like yours. If you email deputies[at]admin.spamcop.net with your IP address and a brief explanation, your IP can be removed from the list.

Share this post


Link to post
Share on other sites

Spamcop's policy is not to report "virus" emails.

The Virus notification sent from the AV programs do not fall in this category and IMHO anyone who sends them to virus/worms that are known to pick names at random to use as the "From" address should be reported.

There are many home/personal users that do not have a clue but a network/email admin for a company that "admits" they know this and still sends them to an innocent "victim" should be reported and their company should be notified that their irresponsible adminitrator is not making their company look very good.

Share this post


Link to post
Share on other sites

You said:

We have decided against disabling the virus notifications for the following reasons:

a) Our links to emergency services such as Fire & Rescue, Police & Paramedics.

B) Confirmation / Courtesy a senders email was received therefore allowing them to re-send a virus free email.

c) With today’s society relying heavily on email it would be un-realistic of us to delete an email, received from another and not notify the sender.

d) The amount of traffic our IT helpdesk would receive in relation to 'lost' email would be unsustainable.

I have no idea what antivirus autoresponses have to do with emergency services links but anyway:

You are *NOT* notifying the sender; you are sending these to people who *never* sent you a virus and have *nothing* to do with your server receiving virus mails. You are mailbombing innocent email addresses. Most people have turned off these autoresponders.

The amount of traffic that you are causing other people and other helpdesks is unfair -- what do you think happens when some totally innocent person receives one of your misdirected messages? They get all worried that they have a virus, they call their ISP, they tie up their ISPs resources.

Close enough to 100% of the current virus traffic has totally forged "from" addresses for me to say that 100% of the antivirus autoresponses are going to the wrong place. On a forum of admins that I participate in, admin after admin is saying the same thing: we had our defenses up to deflect all incoming mydoom within a hour or two of hearing about the new virus *but* we are overwhelmed with anti-virus autoresponses coming to us and our users and those autoresponses are creating all kinds of problems.

Most people have turned these autoresponses off.

Share this post


Link to post
Share on other sites
You are  *NOT* notifying the sender; you are sending these to people who *never* sent you a virus and have *nothing* to do with your server receiving virus mails. You are mailbombing innocent email addresses. Most people have turned off these autoresponders.

The amount of traffic that you are causing other people and other helpdesks is unfair -- what do you think happens when some totally innocent person receives one of your misdirected messages? They get all worried that they have a virus, they call their ISP, they tie up their ISPs resources.

Close enough to 100% of the current virus traffic has totally forged "from" addresses for me to say that 100% of the antivirus autoresponses are going to the wrong place. On a forum of admins that I participate in, admin after admin is saying the same thing: we had our defenses up to deflect all incoming mydoom within a hour or two of hearing about the new virus *but* we are overwhelmed with anti-virus autoresponses coming to us and our users and those autoresponses are creating all kinds of problems.

Most people have turned these autoresponses off.

As a mail admin I have, and continue to with each new virus, write filter rules to reject virus notifications from improperly configured AV software. The support hassles of having to deal with clients that have been mislead to believe they are infected is amazing. I've heard about the creation of block lists specifically designed to block servers that create these types of abuse...

Share this post


Link to post
Share on other sites

This post has created some great answers, I wonder if it was just a hit and run post and they will never change or get a real grasp on the problem they are causing.

Share this post


Link to post
Share on other sites

Our SOP with viral virus responses is to write to the administrator of the system once, letting them know they've sent an unsolicited commercial reply to a forged address, and future responses like the original will get them on our personal blacklist.

I see e-mails like those as spam, even tho I don't report them here.

Share this post


Link to post
Share on other sites
This post has created some great answers, I wonder if it was just a hit and run post and they will never change or get a real grasp on the problem they are causing.

Well I'm back and my thoughts exactly, this post has created some great answers. I personally thank you all for your time and efforts.

After reading your responses I now feel I have some real ammunition to present to our corporate IT department & senior management regarding this topic.

After considering your posts I agree with your common view that Antivirus notifications constitute spam. With the MyDoom worm seriously affecting the quantity and therefore legitimacy of these notifications the side effects (spam, increased server load, etc) far out-weigh any usefulness they may have provided.

Your time is near virus notification...!!

I have no idea what antivirus auto responses have to do with emergency services links but anyway:

One of the concerns presented by senior management, for not disabling virus notifications, is the amount of and reliance on email communications between our organisation and the State Emergency Services.

Whilst I agree we cannot rely on email and this viewpoint is clearly communicated to staff, a great deal of communications between ourselves and emergency services is via email. Obviously any incident where ones life or property are under threat other reliable, fault tolerant communications are used.

1. Reject the mail with SMTP codes.

2. Send a rejection mail to the postmaster address for the I.P. address you received the undeliverable e-mail or bad content from.

Thank you for your suggestions. I wish to explore these options in a greater detail and specifically how to implement them in our IT environment. Presenting options to management (along with my personal feelings about spam) will really strengthen the argument for switching virus notifications off.

Would you please explain the theory behind rejecting mail with SMTP codes?

Where would this be configured: on the mail server or the mail sweeper?

On a side note the following link, posted on Slashdot recently, provides some interesting reading on this topic.

Anti-Virus Companies: Tenacious Spammers

Share this post


Link to post
Share on other sites

Would you please explain the theory behind rejecting mail with SMTP codes?

Where would this be configured: on the mail server or the mail sweeper?

The idea is that when a computer connects to your mail server, your mail server checks the incoming email to see if it is a virus before it responds with the final "OK" code. If it find the email is a virus, it responds with an error code before the sending computer ever disconnects. It can then just delete the email.

This allows the true sending computer to be notified that the message has been rejected. 99% of the time, this is a computer with a virus on it and it's not going to care. In the extremely unlikely situation that an actual correspondent of yours was sending you a message and it had a virus or something like that, then they should receive a bounce message from their own mail server.

To do this, your mail server would have to specifically support it and have virus scanning integrated. Most don't.

JT

Share this post


Link to post
Share on other sites

I disagree with much that has been said.

I am concerned that a number of people in this thread have seemingly ignored the fact that Spamcops rules indicate that the user should not submit spamcop messages for "bounces generated because of spam forged in your name". They seem to feel that such bounces are spam. ("[They will never] get a real grasp on the problem they are causing.")

1. A virus notification is a form of an "Undeliverable Mail" DSN (Delivery Status Notification) message, not spam.

Bounce messages are valid mail, and even required by the RFCs.

RFC 2821 (http://www.faqs.org/rfcs/rfc2821.html)

"If an SMTP server has accepted the task of relaying the mail and

later finds that the destination is incorrect or that the mail cannot

be delivered for some other reason, then it MUST construct an

"undeliverable mail" notification message and send it to the

originator of the undeliverable mail (as indicated by the reverse-

path).  Formats specified for non-delivery reports by other standards

(see, for example, [24, 25]) SHOULD be used if possible."

where 24 = RFC1891 and 25 = RFC1894

Even though the RFCs require it, I would think it prudent to avoid generating a DSN when the system can detect that the mail was forged (in particular when the content matches a known forging worm's signature). However, anyone's assertion that such a DSN message is spam seems to ignore the standards required of the Internet.

2. Re the claim that anti-virus systems "spam" because they identify themselves.

a ) The one we use, Symantec's NAVSMTP, as we have it configured, does not identify itself (which I think is wrong, but then I don't control it).

b ) RFC 2821 addresses the issue of (mail) systems identifying themselves (as a security issue, not as an advertising issue). As I read it, the RFC indicates that making this system available allows debugging which, in their opinion, outweighed the argument for security-through-obscurity. I feel the same way about anti-virus s/w. I also feel it is appropriate for me to see who is using what so I can better evaluate what AV s/w might be best.

c ) Of course it is wrong if the AV s/w does more than identify itself, what it found, what site applied it, and maybe a contact address. But those basics do not constitute spam any more than an User-Agent heading in the header of a message.

3. In our case, someone (IMHO, erroneously and in violation of http://news.spamcop.net/cgi-bin/fom?file=14) reported our site to Spamcop in response to the following situation.

This is NOT a case of a virus notification message, but is a person reporting a "bounce" message that was a result of forged worm mail. But it illustrates some of the intricacies of mail delivery & bounce messages.

Worm at 1.2.3.4 forges mail from nobody[at]example.com (with legitimate names, of course) and sends it to mailing-list[at]oursite. The MX for oursite disables (replaces with a message) the worm code in the message and continues the delivery (This modification is technically in violation of RFC2821 2.3.8 but seems to be a valid attempt to deliver the message. Please remember that not all viruses are mass-mailing & forging.)

The mail is relayed to the host that is responsible for handling the local part "mailing-list". At this point, it is technically out of the SMTP protocol and is just mail that is to be delivered "locally".

The mailing list software then gets the submitted mail. Because the mail does not meet the standard for the mailing list (in this case, because the (alleged) sender is not authorized to submit to the list), the mail is not sent to the list.

At this point, the mailing list software (in our case, Listar) generates a "bounce" message to the sender. There is NO way that this software might reasonable infer that the sender was forged or that the mail ever contained a worm. Nor should it.

"Bounce" is in quotations because the message is not in a format specified by RFC 1894. In my opinion, this is a bug (even though I believe the software predates that RFC). However, to a human, the mail is clearly seen as a "Your message was rejected because ..." message.

The innocent person, whose address was forged, received this "bounce" message and reported it as spam. I am sympathetic that the person may be clueless about what happened but they can clearly see that the message is a bounce message and contains no self-promoting message of any sort and therefore should not have reported it to Spamcop. (Obviously I don't know the individual who reported the "spam" but I wonder if this was an (semi-)automated report. An auto-responder reporting a different auto-responder.)

I understand that Spamcop can not automatically detect our bounce message as being a bounce message. I don't know, but I hope that Spamcop will detect many DSN messages (as formatted according to RFC1891 and RFC1894) and ignore those reports.

It is our intent to find a better mailing list processing software but it will not happen soon. I now better understand the need for it to generate properly formatted bounce messages.

4. Regarding the issue of using SMTP codes to reject mail.

This is an unnecessary sidebar to the discussion and only clouds the issue. All the error code does is to change who generates a bounce message.

Suppose spammer inserts mail on host Source-Host to be delivered for Dest-Host with a forged address of nobody[at]example.com. In order for the MTA at Dest-Host to reject the mail via SMTP because it has a virus, it has to run the mail through a virus scanner of some sort. All that time, it must keep open the SMTP connection from Source-Host. The problem gets even worse if you think of the MTA also checking for spam which might include offsite queries to check to see if the mail body has been reported as spam. So, after some possibly non-trivial amount of time, if it decides it doesn't want the message, it reports a 550 SMTP error message (which is pretty non-specific!).

All that time, Source-Host and Dest-Host were keeping open the SMTP connection. Granted that's not too much overhead, but I think most mail systems balance the number of SMTP connections with the amount of effort to send/receive mail in order to not overload their system. Changing the nature of whether the connections are actively transmitting mail or just sitting around waiting for s/w to run will upset that balance. What should have been maybe a <0.1 second transmission might become a 5 or 10 second transmission time.

Ok, suppose finally that Dest-Host rejects the mail. Now, it is Source-Hosts's responsibility to report that non-delivery to the (alleged) sender. The poor innocent gets the bounce message from Source-Host.

Suppose Dest-Host simply accepted the mail and then later decided it was spam and decides not to deliver it to "nobody". In this case the poor innocent gets the bounce message from Dest-Host. Not much difference.

The only difference I see is that Source-Host might get overwhelmed delivering the bounce messages as well as spam, if a lot of spam was being sent from Source-Host. But that difference is gone if the destination host has an MX host that accepts the mail first with a subsequent relay to the destination host (Dest-Host) where the virus/spam checking is done. (Our site actually has separate MTAs that do spam and virus checking. One of them won't be first in line!)

Share this post


Link to post
Share on other sites
And they advertise their software in the reply.

The above quote refers to Antivirus Companies advertising in their automated responses.

But this from SPAMCOP:

Your message has encountered delivery problems

to the following recipient(s):

somename[at]somedomain.com.au

Delivery failed

550 5.2.1 Mailbox unavailable. Your IP address REMOVED_IP is blacklisted using SPAMCOP. Details: Blocked - see http://www.spamcop.net/bl.shtml?REMOVED_IP.

No recipients were successfully delivered to.

AND This:

Your message has encountered delivery problems

to the following recipient(s):

somename[at]somedomain.com.au

Delivery failed

550 5.7.1 Defined spam source: bl.spamcop.net

Sent:    MAIL FROM:<somename[at]somedomain.com.au>

Received:550 5.7.1 Defined spam source: bl.spamcop.net

Please note I have removed the IP addresses and names from the above examples.

In all reality not having a link to SPAMCOP would provide greater frustrations for someone trying to troubleshoot a delivery problem of this type. Your still advertising though?

Share this post


Link to post
Share on other sites
<snip>

But this from SPAMCOP:

Your message has encountered delivery problems

to the following recipient(s):

somename[at]somedomain.com.au

Delivery failed

550 5.2.1 Mailbox unavailable. Your IP address REMOVED_IP is blacklisted using SPAMCOP. Details: Blocked - see http://www.spamcop.net/bl.shtml?REMOVED_IP.

No recipients were successfully delivered to.

That isn't from SpamCop -- it's from an ISP or e-mail provider that uses SpamCop BL (block list).

AND This:

Your message has encountered delivery problems

to the following recipient(s):

somename[at]somedomain.com.au

Delivery failed

550 5.7.1 Defined spam source: bl.spamcop.net

Sent:    MAIL FROM:<somename[at]somedomain.com.au>

Received:550 5.7.1 Defined spam source: bl.spamcop.net

Again, that isn't from SpamCop, that's from an ISP or e-mail provider using SpamCop BL.

In all reality not having a link to SPAMCOP would provide greater frustrations for someone trying to troubleshoot a delivery problem of this type. Your still advertising though?

You'll have to take that up with the service provider(s) that used the SpamCop BL to block the e-mail.

Edited by turetzsr

Share this post


Link to post
Share on other sites
In all reality not having a link to SPAMCOP would provide greater frustrations for someone trying to troubleshoot a delivery problem of this type. Your still advertising though?

In all reality accusing an innocent person of sending you a virus and giving them a link to antivirus software to clean their machine is related, how? :blink:

Share this post


Link to post
Share on other sites
In all reality accusing an innocent person of sending you a virus and giving them a link to antivirus software to clean their machine is related, how?

So assuming an innocent person is accused of sending you a virus why would you not provide them with a link to clean their machine? I would consider that a courtesy. Providing them with a link 'offers' them the chance to identify the virus and either update their failing antivirus software or simply install one.

Its about taking that extra step to not only inform someone of a virus but to offer some assistance in its removal.

In saying that have a reserved opinion about sending notifications in the first place, primarily because these notifications may be sent to an innocent person.

MWTyson Thanks for your informed post. Please allow me a little time to digest all that you have presented. I appreciate all your typin :) You have really added value to this topic.

That isn't from SpamCop -- it's from an ISP or e-mail provider that uses SpamCop BL (block list).

I see your point. However in the context of antivirus notifications being branded advertising it is the ISP's or email solution providers who configure these antivirus notifications, just like its the ISP's who configured the SPAMCOP notifications.

In saying that I would like to leave the point of advertising alone as it does nothing to contribute to the original post. Feel free to comment though. I just don’t feel we are going to get any constructive results from that topic :)

Share this post


Link to post
Share on other sites
(CreatationX)

So assuming an innocent person is accused of sending you a virus why would you not provide them with a link to clean their machine? I would consider that a courtesy. Providing them with a link 'offers' them the chance to identify the virus and either update their failing antivirus software or simply install one.

If you want to do them the courtesy, notify the postmaster for the I.P. that the virus came from.

Several mailing lists that do not require subscriptions are being overrun with these useless virus notices.

Several people that I see posting on the spamcop.net newsgroups, and other newsgroups are losing real e-mail because they can not delete the bogus virus notices that are being sent to them faster than they use up their mail storage quota.

The DSN's from the forged addresses are also causing these problems. If they used SMTP rejects instead, or sent the notifications to the postmaster[at][x.x.x.x] address, this abuse would not occur.

Any system that automatically responds to any message that is sent to it with out doing some sort of validation on it has the potential for abuse by others.

And right now, a virus scanner that notifies anyone other than the postmaster or abuse address of the sending network is abusive, and is definitely causing real e-mail to be lost.

(WMTyson)

I understand that Spamcop can not automatically detect our bounce message as being a bounce message. I don't know, but I hope that Spamcop will detect many DSN messages (as formatted according to RFC1891 and RFC1894) and ignore those reports.

Spamcop.net has several checks to attempt to prevent reporting of Viruses, and DSN reports. I can not say how accurate they are, except that in the last year, I have never seen it allow a DSN that I was looking up the source to be to reported.

Real mail servers generate DSN reports, infected systems do not, so using SMTP rejects is a way to mitigate the problems that the victims of address spoofing has.

And it has been posted several times that spamcop.net users are not to report "worm poop" through it. That includes false virus notifications, bounces, and worms.

They are also not suppose ot report subscription confirmation requests to confirm opt in requests, or challenges from challenge response systems.

The spamcop spamtraps may have different criteria as to what they will report. And other DNSbls will also automatically list on a spamtrap hit.

There is at least one DNSbl (not spamcop.net) that explicitely lists mail servers that send out DSNs and worthless virus reports to innocent victims.

While it use to be a courtesy to send a DSN to the apparent sender, now it is abuse in almost all cases. If you can not use the SMTP reject, and feel a DSN must be sent, direct it to the POSTMASTER[at][x.x.x.x], for where the message was received. That address must exist to be RFC compliant.

In adjusting the mailing list software for handling non-subscribers, an automatic procedure should use SMTP bounces. If you can not use SMTP bounces, then such rejections should be approved by a human. The volume of these misdirected postings should be low enough that this could be done.

If you are trying to control spam into the mailing list this way, I would hope that you are first eliminating all known spam sources such as open proxies, open relays, and domains owned by spammers before they even get into the mail server.

-John

Personal Opinion Only

Share this post


Link to post
Share on other sites
I disagree with much that has been said.

I am concerned that a number of people in this thread have seemingly ignored the fact that Spamcops rules indicate that the user should not submit spamcop messages for "bounces generated because of spam forged in your name".  They seem to feel that such bounces are spam.  ("[They will never] get a real grasp on the problem they are causing.")

1.  A virus notification is a form of an "Undeliverable Mail" DSN (Delivery Status Notification) message, not spam.

Bounce messages are valid mail, and even required by the RFCs.

RFC 2821 (http://www.faqs.org/rfcs/rfc2821.html)

"If an SMTP server has accepted the task of relaying the mail and

   later finds that the destination is incorrect or that the mail cannot

   be delivered for some other reason, then it MUST construct an

   "undeliverable mail" notification message and send it to the

   originator of the undeliverable mail (as indicated by the reverse-

   path).  Formats specified for non-delivery reports by other standards

   (see, for example, [24, 25]) SHOULD be used if possible."

where 24 = RFC1891 and 25 = RFC1894

Even though the RFCs require it, I would think it prudent to avoid generating a DSN when the system can detect that the mail was forged (in particular when the content matches a known forging worm's signature). However, anyone's assertion that such a DSN message is spam seems to ignore the standards required of the Internet.

This states that a non-delivery report be sent. I don't see where it requires AV users to reply to a forged sender notifying them that they supposedly sent a virus. Bounces being reported as spams are completely different.

Share this post


Link to post
Share on other sites
1.  A virus notification is a form of an "Undeliverable Mail" DSN (Delivery Status Notification) message, not spam.

Bounce messages are valid mail, and even required by the RFCs.

...

anyone's assertion that such a DSN message is spam seems to ignore the standards required of the Internet.

Bounce messages can be valid mail, and they are required by the RFCs in certain circumstances. That doesn't mean that they can't also fit the definition of spam.

2.  Re the claim that anti-virus systems "spam" because they identify themselves.

...

As I read it, the RFC indicates that making this system available allows debugging which, in their opinion, outweighed the argument for security-through-obscurity.  I feel the same way about anti-virus s/w.

Identifying the system which generated/relayed a message is desirable. I don't think anyone claimed that the systems merely identifying themselves is considered spamming. Identification is possible with a couple of words, which could be stored away in the message header. What isn't necessary is to have the full name of the software company, the name of the product, a URL to the companies software, or any verbiage about what the product does or how effective it is, in the body of the message. Some software is worse than others for this...

Please remember that not all viruses are mass-mailing & forging.

No, but the vast majority currently circulating are.

The innocent person, whose address was forged, received this "bounce" message and reported it as spam.

...

I don't know, but I hope that Spamcop will detect many DSN messages (as formatted according to RFC1891 and RFC1894) and ignore those reports.

There's no disagreement that what they did was wrong by Spamcop's policies. Spamcop does have checks to try and avoid users sending reports about bounces and viruses, but they're can't be perfect. If your server isn't already delisted, if you post the IP or email deputies[at]admin.spamcop.net with the IP and an explanation, it will be delisted, and the user who reported it educated as to their mistake.

4.  Regarding the issue of using SMTP codes to reject mail.

This is an unnecessary sidebar to the discussion and only clouds the issue.  All the error code does is to change who generates a bounce message.

I don't think so, and it's not necessarily true that that is all it does.

Suppose spammer inserts mail on host Source-Host to be delivered for Dest-Host with a forged address of nobody[at]example.com.

...

Ok, suppose finally that Dest-Host rejects the mail. Now, it is Source-Hosts's responsibility to report that non-delivery to the (alleged) sender. The poor innocent gets the bounce message from Source-Host.

That's true in those particular circumstances. However, source-host is often the spammer's machine, or in the case of viruses, the virus-infected PC. If either a spammer's specialised spamming software, or a self-mailing virus (such as MyDoom), gets the reject code, no bounce will be generated. If the spammer has used an open relay as "source-host", then recipients can block the bounce messages by blocking mail from the open relay (which many people do anyway using third-party relay lists), rather than having to block email from dest-host.

It's true that it's possible to be RFC-compliant and still generate these kinds of messages. The point is that it's also possible, usually without much extra effort, to be RFC-compliant without generating undesirable bounce messages.

Edited by michaell

Share this post


Link to post
Share on other sites
I disagree with much that has been said.

I am concerned that a number of people in this thread have seemingly ignored the fact that Spamcops rules indicate that the user should not submit spamcop messages for "bounces generated because of spam forged in your name".  They seem to feel that such bounces are spam.  ("[They will never] get a real grasp on the problem they are causing.")

1.  A virus notification is a form of an "Undeliverable Mail" DSN (Delivery Status Notification) message, not spam.

Bounce messages are valid mail, and even required by the RFCs.

RFC 2821 (http://www.faqs.org/rfcs/rfc2821.html)

"If an SMTP server has accepted the task of relaying the mail and

   later finds that the destination is incorrect or that the mail cannot

   be delivered for some other reason, then it MUST construct an

   "undeliverable mail" notification message and send it to the

   originator of the undeliverable mail (as indicated by the reverse-

   path).  Formats specified for non-delivery reports by other standards

   (see, for example, [24, 25]) SHOULD be used if possible."

where 24 = RFC1891 and 25 = RFC1894

Even though the RFCs require it, I would think it prudent to avoid generating a DSN when the system can detect that the mail was forged (in particular when the content matches a known forging worm's signature). However, anyone's assertion that such a DSN message is spam seems to ignore the standards required of the Internet.

This states that a non-delivery report be sent. I don't see where it requires AV users to reply to a forged sender notifying them that they supposedly sent a virus. Bounces being reported as spams are completely different.

spam is unsolicited and unwanted email. The kind of spam that is usually the problem is UBE and that's mainly what spamcop allows to be reported. It also allows reporting of UCE (and that does not need to be bulk).

Virmen are unsolicited and unwanted and therefore are spam. They are often also bulk. However, spamcop does not allow virmen to be reported. It also does not allow the unsolicited and unwanted "bounce" email messages sent to forged addresses to be reported. However, these are also spam.

Both antiviral notifications and virmen can be reported to the sending ISP manually. Email messages that announce undeliverable email that was never sent and challenge response messages to emails that were never sent can also be reported manually to ISP's as unsolicited and unwanted .

There was, at one time, talk about setting up a virus bl similar to spamcop, but I don't know what happened to it. IMHO, it would be a really good idea if it were simple enough for the average person to use. It might even stop a viral infection sooner.

Miss Betsy

Share this post


Link to post
Share on other sites
Virmen are unsolicited and unwanted and therefore are spam. They are often also bulk. However, spamcop does not allow virmen to be reported.

I just love that.... virmen. It definitely classifies the unwanted viral marketing of AV products through "concerned" e-mails about our protection. It's too bad that virmen can't be reported thru spamcop. They're not bounces, and I can't justify the classification of them being bounces. If the AV companies are going to be getting into mail admin, I'd like to suggest that they come up with a better mousetrap instead of losing their cheese over every spoofed e-mail address.

I usually send the virmen back to the mail administrator with the suggestion that it is considered to be spam, and I send a copy along to their upstream provider.

Of course, I use my admin ID when I do that.... :ph34r:

Share this post


Link to post
Share on other sites
It is a violation of Spamcop terms of service for members to use it to report viruses, or misconfigured mail servers that should not be sending out virus notifications to innocent parties.

More effort needs to be made to inform SpamCop users of SpamCop policy.

Specifically at the point a user 'submits' spam notification to SpamCop.

It takes only a second for an uninformed user to click submit / send but may take hours even days to resolve incorrect listings by SpamCop. You owe it to your users and supports to get this right.

SMTP Filtering

Again thanks for your suggestions, we are currently reviewing the implementation of this.

Share this post


Link to post
Share on other sites

My company is using Sophos AntiVirus solution as well. And we didn't use PureMessenger to hold back those Spammers but the AV feature is quite updated except for the notificiation.

Maybe we can gather Sophos + SpamCop user and have a better discussion ?

Share this post


Link to post
Share on other sites

Does anyone have a boilerplate response that can be sent to mail admins in reference to the subject?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×