Hi kwdavids,

The main gist of the thread seems to be concerning sending a bounce that has been changed to notify the person it is infected and they need to visit a specific website to clear their machine.  As noted on that forum, typical bounces are accepted and expected Internet protocol when a nonexistant address is used, and the server returns a bounce to the sender to notify them of this.  If an infected computer is sending mail to a nonexistant address on my domain, they should receive bounces so they know they are even doing it.  They cannot report me to spamcop because a bounce message is protected and not abusive so long as I don't change the message to sell products or otherwise.  I would be able to win a case against spamcop blacklisting my domain for bouncing virus emails back to the sender since those certainly aren't spam on my part, and rather accusing the person attacked (the victim) of being the perpetrator of the crime...

Anyway, just my take on the matter.  It is a long thread and I might have misunderstood the main points of it. I'll re-read it later to be certain I am accurate in my understanding.

Thanks since it is a good discussion and you always have enlightening and helpful information on email issues.

Have a Blessed Day

The thrust of the discussion is about virus bounces. The thread argues that if the SMTP server rejects a message, it should return an error code, or send notification to the postmaster of the sending domain, not send a message to a forged sender address.

To send a bounce message to someone who didn't originate the message is abusive--it's an unsolicited commercial email. The practice amplifies the pain from email viruses, taxes the resources of abuses desks, clogs mailing lists and generally causes all sorts of problems, as described in the thread.

The serious issue that Lunarpages needs to come to grips with is that more and more users are reporting forged virus bounce messages to the various abuse databases, and forged address bounce messages can end up in "spam traps". This means that Lunarpages servers are going into black hole databases (as Orion was yesterday), and this impinges on the ability of their customers to send email.

Hello,

I understand what you are saying.

In your first of the two posts you just made above, in the first paragraph, you are suggesting that it might be possible to send notification to, lets say, postmaster@lunarpages.com

instead of sending it to who it apparently seems to have been sent from.

In practise, this would mean that postmaster@lunarpages.com would have millions of e-mails per day and more importantly, no one would know if their e-mail had arrived or not.


I am very aware of the problems that bounced e-mails can cause, not only because I get about 100 per day!

Viruses send out copies of themselves to all sorts of addresses, some made-up, and bounced messages come back to me.

Sending them back to a "postmaster" account wouldn't solve the problem. The server at the other end does not know if it is a genuine e-mail or not....

Not having a bounced message at all causes a problem for legitimate mail.


The whole situation is flawed due to the people who originally wrote the SMTP protocol back in the dark ages.

Viruses are able to send e-mails apparently from other people's addresses due to the lack of the protection in the SMTP protocol which should check that the sender is actually who they say they are.

Until the e-mail protocols of the internet as we know it are rewritten, you will get bounced e-mails, and there is nothing anyone can do about it.

Finally though, spamcop will not blacklist a server due to bounced e-mails. The people who run it are aware that there are viruses out there sending fake e-mails. They have to police the content of the complaints they recieve. If they didn't, there would not be much point in using their service, it would be useless.

Well, that would only happen if Lunarpages servers were sending out millions of virus-infected emails.

I've never tried to send a virus out through Lunarpages, but I think it would be a good thing if that were blocked. If the Lunarpages domain never sent out a virus-infected email, then its postmaster would never get a rejection message.

I hear you about this "never know if their e-mail had arrived", although one really never knows...

But for example, I sent a complaint to the abuse address of somebody who sent me a forged virus rejection. I sent the email to my ISP's SMTP server, and it tried to relay it to the destination. For some reason, that destination server wasn't responding. I eventually got a non-delivery message back from MY SMTP server that it couldn't deliver the message. I got notification of non-delivery, but the remote SMTP server didn't send me any bounce. That's a better way--if an SMTP server won't accept the message, it should return an error code, not generate an email. Sending bounce messages is really going around the trusted relay mechanism already designed into SMTP.

Hmm.

If some spam blocking organisation blocks e-mails without even investigating, then they are definately not worth using.


The latest virus "mydoom" doesn't use the lunarpages servers to send mail, it uses the infected computer to send mail directly, not through a lunarpages server.

If the mail is sent with a spoofed address from a lunarpages customer, then they will get the bounced message.

If all bounces were sent to a "postmaster" address, then the "postmaster" account would get the bounces.



You wrote above "If the Lunarpages domain never sent out a virus-infected email, then its postmaster would never get a rejection message."

That is not entirely correct though...

If I had the virus on my computer, and it sent out an e-mail, appearing to come from your e-mail address, to a made-up address, then you would still get a bounced e-mail, even though lunarpages was not involved at all.


The reason that you are getting bounced e-mail reports from all sorts of servers, and not just the lunarpages one, is that you are not sending the e-mail.

That's the whole point of this stupid virus, the messages are spoofed, and not sent through your own server.

Bounced e-mails (error messages) always come from your own server, unless the message is faked.

I believe that I understand what Kevin (kwdavids) is talking about as I have gotten some of them too, and I consider them an nuisance (luckily too I have and use AntiVirus protection and Pegasus Mail rather than Outlook... latter just for more protection).

What I believe Kevin is talking about is that emails come into his email address from "some" email servers, saying that it is a 550 user unknown email, or for some other reason is returned. This returned email was, for example, a spam or virus sent to somearbitraryname@somedomain.com  --- where it is a spam or virus that was sent the Reply to and From email address fields were forged, in this case with Kevin's email address (or anything@atkevinsdomain.com)

The receiving mail server at somedomain.com has seen that somearbitraryname@somedomain.com is not a valid email address at somedomain.com (thus the 550 error code) or for some other reason (eg they might block from all sender emails not at AOL or whatever) so the mailserver that handles the email for somesdomain.com bounces it back to the sender..... BUT that mailserver (wherever) is not handling the "return error" properly!!!!

That mailserver is sending the bounce (along with copy of what had been sent) back to the FORGED EMAIL (that was giving for that spam or virus).

That mailserver "should be" sending the "bounce" back to the postmaster at the SOURCE IP that it received the email from..... that's the IP number contained in the topmost/first received line of emails. That is the IP which Can Not Be Forged as it is the true source of origination (or source of relay).

Might be just a bug in "standard prototocol" or mailserver programs, but I (too) can not see why the mailserver that is receiving email upon finding that an addressee is INVALID could not First do at least an IP lookup of the From-Email-Address-Domain to see if that domain's IP matches with the Source IP that the mailserver actual has already seen or gotten. If the senders-email-address-domain matches the IP number, then fine, the "bounce" could go directly to that email address specified, BUT---- if the email was senders email was forged and thus NO MATCH of domain IP to the actual Source IP THEN OF COURSE it should go to postmaster@SourceIP

What Kevin finds a nuisance and abusive (me too a bit), is that the spam or virus that was sent to somearbitraryname@somedomain.com by a mailserver (example) in CHINA with Kevin's email address used for the From and Reply to.

Kevin is not in China, he did not send it, and the receiving mailserver "should have" been able to determine that Kevins-Domain-At-Lunarpages.com is not in China or whatever Source IP, thus a "bounce" should not have went to Kevin but to should have been sent to postmaster@Source IP.

To correctly send a bounce back to the postmaster at Source IP could possibly also aid in stopping some spammers, or could possibly alert some mailservers that they have an open relay or a security issue.

Hope this explains what Kevin was complaining about.

I'm hoping that this "bug" for "bounces" might also get fixed but then there's various mailserver programs and lots of systems out there. I just live with it myself and try to otherwise "filter" the best that I can.

Any hope for Kevin and others in the future? hmmm... only time can tell.
Hope this is what you were talking about too, Kevin, and hope that it gives "some" explanation.... hopefully you don't get too many of those bounces, there's lots of mailservers out there and of course the latest virus was a big hitter going out to lots of places and people.

Regards,
 

Maybe a quick comment on how email is supposed to work:

I send an email. It goes to an SMTP server that belongs to my local service provider. My email client is notified that the SMTP server accepted the email.

Then my ISP's SMTP server tries to connect to the SMTP server where the email is to be delivered. That either works or not. If it works, that should be the end of it. If the remote server refuses to accept the message, it returns an error code. My ISP's SMTP server, when it decides that it can't deliver my message, will send me an email letting me know it wasn't delivered. My ISP knows what emails I entrusted to it, and I never get a false notice from my ISP about the delivery of something I didn't send.

What's happening now, with these virus-infected emails, is something outside the chain of events I described. A virus filter somewhere in the final destination mail system takes upon itself the responsibility for notifiying by email the sender of a virus-infected email that they are sending viruses and that their email wasn't delivered. (It's not a "bounce" in the normal sense.) However, the mail system is not smart enough to know who sent the virus, so it sends the notice to somebody else -- meaning that (A) the sender of the virus is not warned and (B) an innocent bystander is accused.

What Lunarpages did (on the one instance I was involved with this) was to send a message that "my" email was blocked because it contained a potentially dangerous attachment, a .PIF file. The email I received leads me to believe that Lunarpages blocks all emails with .PIF attachments. The problem was that Lunarpages' email system was not smart enough to recognize who the mail came from, i.e., (A) the sender of the virus was not warned and (B) an innocent bystander was accused.