Bouncing vs. Eating - again

[Lutz]

Hi @ll,

this is what happened today.

In my eaten mails log I found an email that was sent by a former schoolmate of mine who did not know my real email address. As he did not know it because I had never given the address to him, he must have tried to find it by using google.

He probably found several email adresses together with my real name, but I have not used these addresses for a while, changed my accounts, closed accounts etc., so he received the usual error message from all of these saying that the user or the account does not exist.

The SG that he found was for newsgroups, but after I received enough feedback via that address I set its counter to 0 so no new mail would come through. It was by accident that I looked at the website of SG and my eaten log today and noticed he tried to send me something and did not succeed.

Unfortunately, as SG never sends back any messages whether or not delivery was no success, my school mate now will assume the mail address was indeed correct, and because he did not receive any error messages he must assume now I do not want to respond and the mail itself arrived at where he sent it to.

This is one of the (perhaps rare) occasions where one would like to have some kind of response going back to the originator of an email saying something like "does not exist" or whatever.

Perhaps time to think of a switch for it?

[SysKoll]

Usual request. I'll give you the usual reply: 99% of the spam comes from forged originators (From field). Most eaten messages are spam with such forged fields. Sending back a reply to an eaten email would send streams of messages toward innocent bystanders whose address has been impersonated by spammers. Hint: Search for "Joe Job" on the web.

So we don't do it because it would be a complete nuisance.

[Sebastian]

I'm not that familar with MTAs, but I think rejecting messages with an error code during the SMTP-dialog would do the job: The sender of "normal" mail would receive a bounce message from it's own provider's server (I assume the normal SMTP-path for a mail is My Computer -> My Provider -> Receiver's Provider).

There was a discussion about this feature in the developer's forum. However, one idea about this topic there was to return a error code that indicates a temporarily problem, that could make it useless for the feature requested.

[SysKoll]

I see. The problem is that currently, we accept the message and then we pass it to spameater which possibly rejects it. So the SMTP session is over by the time the message is processed.

The feature you require would mean a big design change. Josh is contemplating several of those, though.

[josh]

One proposal is that we run the spamgourmet code in process with the upstream mail server so that it can participate in the SMTP dialog -- at that point bouncing will be an option (and even preferable for us because we don't have to pull in the whole message), but we'll still need some discussion about user expectations, and we'll probably go with something configurable with a default to eat. Until then, though, we're just not set up for it.

[Jamesd]

One thing you might want to look at is SMTP proxying. That's how SpamPal inserts itself between the net and mail servers so it can tag spam. The C/Windows code for SpamPal SMTP should give you some ideas about how to handle it, even though the details will be a bit different.