Tackling the world’s worst – a workable solution

[washmail]

Please bear with me - there is much info to share here.

For those unaware, the world’s worst spammer (occasionally dropping to second worst) for many years according to spamhaus.org has been one Leo Kuvayev (of both Russian and American origin) otherwise known as ‘Bad Cow’.

Along with his associates he’s responsible for much of our collective ‘unsolvable’ spam which a number of people have referred to here and elsewhere, including the wares of what’s known as ‘the .pdf spammer’ and ‘the stock exchange spammer’.

After much research, ‘signature’ identification (e.g.: ‘Canadian Pharmacy’ – not the real company of course) etc., my colleague and I determined that he was responsible for ALL the cyclic spam we were still receiving (after essentially eliminating all other concerns, mostly through the SpamCop service).

His wide ‘trade’ also includes 419 scams, offering sexual aids, phishing, ‘love’ message links delivering zombie bot generating viruses, and replicas, employment, software and fashion offers.

My colleague supplies domain and email services, so this has been a fairly extensive problem for us and the clients concerned.

We tried everything we could think of to deal with this, some of which led to volatile, denial of service type reactions. (And we believe he’s capable of far worse!)

Until recently our best success was when we supplied detailed, undeniable info on every SpamCop report (and where possible IN THE ISP’S GEOGRAPHIC LANGUAGE!) in the hope of forcing those ISPs that willingly or otherwise cooperate with him to face the grim realities. This was exhausting, and later resulted in him only sending us spam from sources involving his ‘most preferred’ ISPs.

Then I noticed that my email service’s spam filters were getting much better at the job (the best threshold and aggression settings need to be determined first), no doubt due to cooperative ISP partnerships.

But still one has to monitor one’s spambucket constantly…

Then I got the idea to try the following project (the best ideas are always the simple ones):

* I’ve had my ‘Domains Service Provider’ create a pop access type spambucket (essentially it’s just another mailbox), so offering a wider range of control options.

* This will shortly have its auto-reply feature working, allowing one to feedback to all ‘false positive’ sources (normal mail misidentified as spam) which are potential new clients, and among other options the opportunity to communicate politely with innocents who’s email addresses have been hijacked and who must now unfortunately also receive such auto-replies.

* A period-adjustable auto-delete option will then also be added to such spambucket.

* An elaborate setup and regular updating of one’s Whitelist is essential to keep the false positives to a minimum.

And even in this experimental stage it can be seen quite clearly that THIS WORKS!!!

No doubt there will be good days and bad ones, but a few weeks of work have resulted in a mere one or two false negatives (spam getting through) a day maximum, with only a couple of false positives who will in time be so advised automatically! This is on an account which until recently suffered up to 100 spams a day. And shortly I won’t have to look at any of it!!

Of course this solution won’t work for every individual need, but is highly flexible and has much potential.

As we know, most knowledgeable reporters discourage the use of auto-responders altogether, but perhaps it’s got new potential values here.

One thing I’ve noticed – this won’t work well for those who are overly aggressive in the marketplace – good!

One last discovery;

There’s nothing new under the sun – I’ve just discovered a commercial version of ‘my’ idea at http:// www.mailporter.com/about.asp

I can assure everyone that I am in no way connected with them. I don’t even know if they’re reliable or not…

Hoping this can help many of you

(Due to commitments I will not be monitoring this post for some time, so no replies can be offered.

Also, please don’t write to my forum mailbox – it’s not monitored.)

<Moderator Edit> Since you are not affiliated with them, you will not mind me breaking the link so that the searchbots do not get a hold of it. Also, I am going to merge your 2 topics into one to keep all discussion about the merits (or not) of your "plan" in one location.

[washmail]

Please bear with me - there is much info to share here.

For those unaware, the world’s worst spammer (occasionally dropping to second worst) for many years according to spamhaus.org has been one Leo Kuvayev (of both Russian and American origin) otherwise known as ‘Bad Cow’.

Along with his associates he’s responsible for much of our collective ‘unsolvable’ spam which a number of people have referred to here and elsewhere, including the wares of what’s known as ‘the .pdf spammer’ and ‘the stock exchange spammer’.

After much research, ‘signature’ identification (e.g.: ‘Canadian Pharmacy’ – not the real company of course) etc., my colleague and I determined that he was responsible for ALL the cyclic spam we were still receiving (after essentially eliminating all other concerns, mostly through the SpamCop service).

His wide ‘trade’ also includes 419 scams, offering sexual aids, phishing, ‘love’ message links delivering zombie bot generating viruses, and replicas, employment, software and fashion offers.

My colleague supplies domain and email services, so this has been a fairly extensive problem for us and the clients concerned.

We tried everything we could think of to deal with this, some of which led to volatile, denial of service type reactions. (And we believe he’s capable of far worse!)

Until recently our best success was when we supplied detailed, undeniable info on every SpamCop report (and where possible IN THE ISP’S GEOGRAPHIC LANGUAGE!) in the hope of forcing those ISPs that willingly or otherwise cooperate with him to face the grim realities. This was exhausting, and later resulted in him only sending us spam from sources involving his ‘most preferred’ ISPs.

Then I noticed that my email service’s spam filters were getting much better at the job (the best threshold and aggression settings need to be determined first), no doubt due to cooperative ISP partnerships.

But still one has to monitor one’s spambucket constantly…

Then I got the idea to try the following project (the best ideas are always the simple ones):

* I’ve had my ‘Domains Service Provider’ create a pop access type spambucket (essentially it’s just another mailbox), so offering a wider range of control options.

* This will shortly have its auto-reply feature working, allowing one to feedback to all ‘false positive’ sources (normal mail misidentified as spam) which are potential new clients, and among other options the opportunity to communicate politely with innocents who’s email addresses have been hijacked and who must now unfortunately also receive such auto-replies.

* A period-adjustable auto-delete option will then also be added to such spambucket.

* An elaborate setup and regular updating of one’s Whitelist is essential to keep the false positives to a minimum.

And even in this experimental stage it can be seen quite clearly that THIS WORKS!!!

No doubt there will be good days and bad ones, but a few weeks of work have resulted in a mere one or two false negatives (spam getting through) a day maximum, with only a couple of false positives who will in time be so advised automatically! This is on an account which until recently suffered up to 100 spams a day. And shortly I won’t have to look at any of it!!

Of course this solution won’t work for every individual need, but is highly flexible and has much potential.

As we know, most knowledgeable reporters discourage the use of auto-responders altogether, but perhaps it’s got new potential values here.

One thing I’ve noticed – this won’t work well for those who are overly aggressive in the marketplace – good!

One last discovery;

There’s nothing new under the sun – I’ve just discovered a commercial version of ‘my’ idea at http:// www.mailporter.com/about.asp

I can assure everyone that I am in no way connected with them. I don’t even know if they’re reliable or not…

Hoping this can help many of you

(Due to commitments I will not be monitoring this post for some time, so no replies can be offered.

Also, please don’t write to my forum mailbox – it’s not monitored.)

[btech]

sounds like a reply-verification system to me.

That's all well and good, but when you get the email that's FROM you, TO you... then YOU will get the verification email or that spam will slip through.

I'm pleased with SCmail.

[washmail]

sounds like a reply-verification system to me.

That's all well and good, but when you get the email that's FROM you, TO you... then YOU will get the verification email or that spam will slip through.

Yes, it is essentially a reply-verification system, perhaps a better suited variant for smaller businesses / individuals.

You point out a definite weak factor of the system.

In my case, I use a whitelisted alias if I need to send anything to the mailbox in question from elsewhere, and of course do not have the actual address in question in the whitelist.

I'm fortunate in that I haven't received many spams claiming to be from my own address. I'm sure a further, local filter could be used to specifically recognise and remove my own auto-replies.

[washmail]

Further info will be offered once the system is fully functional (expected to be in March, April latest).

[Miss Betsy]

* An elaborate setup and regular updating of one’s Whitelist is essential to keep the false positives to a minimum.

IMHO, the *sender* should always be the one to have to do 'elaborate setup' to send email so that it isn't marked as spam. For one thing, if there are any problems, they can only fixed from the sending end and the sooner the sender knows about them (from server rejections), the better. For another thing, the recipient is /always/ the innocent of unsolicited email. The recipient should have to do very little to keep spam from his inbox and should get all email that he wants because his correspondents are immediately advised that there is a problem if their email doesn't go through and can use alternate means to contact the recipient. Senders need to be responsible for choosing (which, at this time, is utopia) an email service that knows what it is doing and is responsible about spam. (it is utopia, not because there aren't email services that are responsible, but because the consumer has no idea how to choose responsibility)

Miss Betsy

[washmail]

I'm fortunate in that I haven't received many spams claiming to be from my own address. I'm sure a further, local filter could be used to specifically recognise and remove my own auto-replies.

Here's an easier solution;

Put your own address in your own blacklist.

However, this would be problematic if one has multiple pcs set-up to send email as being from the same address, and a Bcc copy needs to be sent back from such other pcs to the mailbox.

Then the previous, local filter option would be needed, or an alias used for each of the other pcs involved.

[DavidT]

* This will shortly have its auto-reply feature working, allowing one to feedback to all ‘false positive’ sources (normal mail misidentified as spam) which are potential new clients, and among other options the opportunity to communicate politely with innocents who’s email addresses have been hijacked and who must now unfortunately also receive such auto-replies.

I'm hoping that doesn't mean what it seems to mean. Would your "system" then be sending auto-responses to innocent addresses that are forged by spammers as the source of the spam? If so, then most of us here will be reporting your auto-responses as spam and we'll quickly get your system shut down or onto the SCBL.

Sending auto-responses to people who did not actually send you messages makes you a spammer, period.

DT

[washmail]

I'm hoping that doesn't mean what it seems to mean. Would your "system" then be sending auto-responses to innocent addresses that are forged by spammers as the source of the spam? If so, then most of us here will be reporting your auto-responses as spam and we'll quickly get your system shut down or onto the SCBL.

Sending auto-responses to people who did not actually send you messages makes you a spammer, period.

DT

This effectively makes all of the very large quantity of innocent parties worldwide who use verification-reply systems effectively spammers. As such, the word 'spammer' is certainly poorly defined.

I will shortly be consulting with both my service provider and the SC deputies in this regard, and (if allowed) will post my findings etc. when concluded.

Flexibility is a necessary advancement tool.

An immediate possible option here that comes to mind is to include a suggestion to potential innocents in the auto-reply to blacklist the sending address if necessary. (As a smaller business, chances are that none of those receiving my auto-reply due to their address having been hijacked would ever have considered using my services anyway.)

Also, in the case of the spammer 'Bad Cow' who (only) is affecting us so badly, he never uses the same address again as far as we can see, nor does he seem to ever use legitimate addresses (although the actual domains used in the addresses sometimes look like they may be real).

I welcome such debate - it's essential to try to find middle-ground wherever possible.

[StevenUnderwood]

This effectively makes all of the very large quantity of innocent parties worldwide who use verification-reply systems effectively spammers. As such, the word 'spammer' is certainly poorly defined.

I will shortly be consulting with both my service provider and the SC deputies in this regard, and (if allowed) will post my findings etc. when concluded.

You are correct... These are called Challenge/Response systems and only protect those using the system while increasing the spam for those whose addresses are forged as the sender since there is no way for a challenge to go back to the original sender except through the use of the reply-to address which is often forged in malware.

There is an entry in the FAQ here, labeled: Say NO to the Challenge/Response Lunacy which is just a pointer to the middle of a thread here: http://forum.spamcop.net/forums/index.php?...amp;#entry16402

SpamCop, in its infancy, also used C/R until it realized the problems once forged addresses became the norm.

Unlike some here, I actually respond to the C/R, especially if I did not send the original because I will then send them an email explaining how they have effectively sent their spam to me. Of cource, that reply also has the side effect of allowing the original spam/virus through to them.

[DavidT]

This effectively makes all of the very large quantity of innocent parties worldwide who use verification-reply systems effectively spammers.

Yes, assuming that a piece of spam with my address forged as either the "From" or the "Return-path" (the envelope from) produces a challenge message sent to my address, then the system sending that challenge to my mailbox is spamming me, plain and simple. If they didn't send me the challenge, then I'd not have received a piece of unwanted email that I would have to waste my time and/or resources on.

Given the current modi operandi of spammers and the lack of effective sender authentication at the mail server level, the best methods of dealing with spam is to either block it during the initial SMTP handshaking based on the IP source, or if accepted, to have it run a thorough gauntlet of effective filters, then to dev/null it if it looks extremely spammy or dump it in a quarantine box if it's marginal. Sending out a challenge to someone whose address is being used without their knowledge or permission is most certainly a bad thing to do, as I'm sure the SpamCop Deputies will confirm.

The only "middle ground" is if the system that engages in "challenge-response" behavior first applies thorough email filters to any incoming messages and then *only* sends challenges to messages that don't appear spammy at all, simply deleting all the rest, but I don't think that's what you're proposing, is it?

DT

[Miss Betsy]

Unlike some here, I actually respond to the C/R, especially if I did not send the original because I will then send them an email explaining how they have effectively sent their spam to me. Of cource, that reply also has the side effect of allowing the original spam/virus through to them.

I tried responding to the abuse address, but got into a catch22 situation because their abuse address also was C/R. And I am one of those buttheads who won't respond directly to an unsolicited commercial email no matter how legitimate it looks. It has taken me three years of reporting to various sources to use the unsubscribe button on one persistent sender who is legitimate, but somehow got my address on its list.

Miss Betsy

[Lking]

Let me see if I understand how this works:

washmail has been getting spam so he set up a system that sends out auto-reply email to all the hijacked From: addresses he receives, thus filling the net with more spam so he " won’t have to look at any of it!!"

To resolve the issue for all the people that didn't know he existed until they got spam (auto-reply) from him is to suggest that, if you don't want spam from me blacklist me.

And this is ok with him because they wouldn't "ever have considered using my services anyway." Well I think he got that right at least.

Flexibility is a necessary advancement tool.

An immediate possible option here that comes to mind is to include a suggestion to potential innocents in the auto-reply to blacklist the sending address if necessary. (As a smaller business, chances are that none of those receiving my auto-reply due to their address having been hijacked would ever have considered using my services anyway.)

Which rule is it about spammers redefining spam so it's not what they do?

[washmail]

Fair enough, the arguments are solid - I see now it's not a solution.

From what I could determine a few posts down in the related topic referred to by Steve, one could get away with this method without being (successfully) reported, but what would that achieve; to use this method would indeed be selfish and merely be adding to the whole spam problem...

At least having converted my spambucket into a pop mailbox, I'm now better able to 'manage' the spam. For those who don't know; this would allow one to use pop mailbox monitoring software which only views the text content of emails, thus making for fast, safe pre-editing of one's mailbox.

I hope all will accept me offering a link for a very respected choice of such software;

firetrust[dot]com (product is called MailWasher)

N.B.: There are plans afoot to make MailWasher capable of accessing many spambuckets directly via IMAP access in future.

(I'm not involved with their business - only hoping to help those who could use the app.)

I would think there are a number of other worthy software options too.

So ends my 'contribution' to this topic. At least I've learnt to do better research in future...

[washmail]

I was considering the closing of a mailbox.

It occured to me that by so doing I would effectively be creating the same traffic, albeit in a different form.

[DavidT]

I was considering the closing of a mailbox. It occured to me that by so doing I would effectively be creating the same traffic, albeit in a different form.

There's nothing wrong with closing mailboxes. Yes, error messages will result when senders, both good and bad, try to hit the address with messages, but as long as the system on which the mailbox formerly resided is rejecting the messages during the initial delivery attempt, and not "after-the-fact," then that system isn't "part of the problem." If, however, the system is configured to send NDR reports as email messages to the perceived senders, they're a big part of the problem.

DT

[washmail]

There's nothing wrong with closing mailboxes. Yes, error messages will result when senders, both good and bad, try to hit the address with messages, but as long as the system on which the mailbox formerly resided is rejecting the messages during the initial delivery attempt, and not "after-the-fact," then that system isn't "part of the problem." If, however, the system is configured to send NDR reports as email messages to the perceived senders, they're a big part of the problem.

DT

Thanks, and the Wiki on NDR helped clarify your explanation.

What I can't understand is why there would be different SMTP rules for the two different modes of the triggering and working of NDR; surely if the IP address path in the header could be used for the sending of a user configured bounce as well, this would result in a tremendous drop in disturbance for all concerned?

No doubt there are good reasons for this differentiation.

Can anyone offer further insight?

[turetzsr]

<snip>

What I can't understand is why there would be different SMTP rules for the two different modes of the triggering and working of NDR; surely if the IP address path in the header could be used for the sending of a user configured bounce as well, this would result in a tremendous drop in disturbance for all concerned?

No doubt there are good reasons for this differentiation.

Can anyone offer further insight?

...From what I understand, the parsing of e-mail headers to find the last sender of the e-mail is something of an art; it is essentially the raison d'etre of the SpamCop parser, by all accounts a very complex program. During the SMTP handshake, the receiving server does not have to do any parsing, it is simply "talking" to the server that is attempting to deliver the message, so it sends its rejection notices directly to the right place (the machine with which it is having the conversation).

[Miss Betsy]

I am not technically fluent so someone who is will probably find things to correct in my explanation.

When the email is sent, it is just 'code'. The receiving email server looks at the 'code' in the headers and can tell certain things like the IP address. If the receiving server is programmed in a certain way (including the use of blocklists), it gives a coded message to return to the sending server. The sending server then gets that message and composes an email to send to the sending user.

If the receiving server 'accepts' the email, then it no longer reads it as 'code' - there is something about DATA stage. Once past accepting the email as DATA, then it reads the email differently. It doesn't look at the headers, but only recognizes the 'return path'. It doesn't parse the headers the way spamcop does to find the sending IP address, but only 'sees' what the email says is the place to return the email to - which may, or may not, be the same as the FROM. The return path is what the spammers forge.

The reason that email was designed this way is that, in the old days when people could be trusted, one could send an email from one address, but have the replies sent to another address. For instance, one could send an email from work, but get the replies at home. Since I wasn't using email at that time, I never learned why it was such an advantage.

As another poster said, accurately determining the correct IP address from the headers is not easy for a program to do - especially since spammers also forge headers. The IP address of the sending server, however, is not easily forged since it is in communication directly with the receiving server. That's why NDRs sent while the two machines are still 'talking' to each other go directly back to the sending server. NDRs sent after acceptance cannot be sent back to the true sending server unless you were to parse, as spamcop does, each email to determine the correct IP address. It can only read the return path.

HTH

Miss Betsy

[washmail]

If the receiving server 'accepts' the email, then it no longer reads it as 'code' - there is something about DATA stage. Once past accepting the email as DATA, then it reads the email differently. It doesn't look at the headers, but only recognizes the 'return path'. It doesn't parse the headers the way spamcop does to find the sending IP address, but only 'sees' what the email says is the place to return the email to - which may, or may not, be the same as the FROM. The return path is what the spammers forge.

Excuse my ignorance, but surely it wouldn't be too difficult for servers to temporarily store the true sending server's identity (and email's reference?) while working post the DATA stage, and to use such info to then accurately bounce when necessary at such later stages?

The reason that email was designed this way is that, in the old days when people could be trusted, one could send an email from one address, but have the replies sent to another address. For instance, one could send an email from work, but get the replies at home. Since I wasn't using email at that time, I never learned why it was such an advantage.

That design still works, or at least it does on my mailservers.

I found it very useful for ensuring that replies from emails I sent to my clients would bypass my ISP's filters.

(I eventually found it better to stop using my ISP's email services altogether. )

[Edited for neatness]

[Miss Betsy]

Excuse my ignorance, but surely it wouldn't be too difficult for servers to temporarily store the true sending server's identity (and email's reference?) while working post the DATA stage, and to use such info to then accurately bounce when necessary at such later stages?

Since I don't really know what happens, I don't know why not. It might have something to do with the conversion from the code to the DATA where what would be stored is not compatible with what is now data. Or it could be that it would take too many resources for a small advantage. Or maybe the email reference (the email address) is not in the same kind of code as the IP address so that one can't store both at the same time. Yes, I think that's it. The email address can't be read - only the receiving IP address. That's probably why servers don't reject at the server level for bad addresses. When the email address can be read, then it is too late to read the IP address without parsing the entire header.

I think it may be possible to code existing email addresses and compare them with incoming code so that they can be rejected at the server level, but it would take too long to compare their whole list of addresses for most large ISPs. The margin of error for someone who really understands filtering is 1% or less so accepting email and then filtering for spam probably keeps email flowing without losing very many legitimate emails that are dumped rather than sent an NDR. The NDR that is sent to the return path is actually a new email.

But all the above is simply guesswork.

Miss Betsy

[StevenUnderwood]

Excuse my ignorance, but surely it wouldn't be too difficult for servers to temporarily store the true sending server's identity (and email's reference?) while working post the DATA stage, and to use such info to then accurately bounce when necessary at such later stages?

The sending server's identity is known because the receiving server (which you would trust since it is your server) will see that IP address and need to communicate with it to complete the transaction. However, any other information is "hearsay" and can be forged by the server sending it to you.

It is a bit like a phone call, you can tell who you are talking to by voice but you can not guarantee what they are saying is true... you are trusting them to trust the person before them, etc. Email was originally based on that trust but spammers have broken that. That is why some (usually older, in my experience) servers still work on the accept first then bounce principle.

[washmail]

Great. So it would seem that in order to make bouncing a potentially fair and legitimate practice, the receiving (I)SP concerned needs to be able to supply a more (modern) appropriate method of handling secondary-stage type bounce options.

[Miss Betsy]

Unfortunately, many ISPs have decided to accept everything rather than simply reject based on blocklists because of the 'innocent' people who are using spam friendly ISPs. The receiving server can send back code which is translated into a message. Sometimes you find posts here from server admins who get a message that says their IP address is blocked by spamcop, but it turns out the receiving server admin is using the spamcop message for all his blocklists.

It is my contention that the spam problem would be solved a lot faster if the end users understood the mechanics of how server admins deal with spam. There are business people who are afraid of offending a customer or losing an unsolicited email who insist on accepting all email - and that's fine. If it ever really costs more to accept spam instead of rejecting it, then they should pay more. However, since it is the *sending* end that can actually do something about spam, IMHO, all users should know that if they use a spam friendly ISP, that their email won't always get delivered.

It would be better to get the rejection message from the server than to have your email 'disappear' because it got tagged as spam after acceptance. Not only would one know that the email wasn't delivered, but one would know why and could do something about it.

Right now, email disappears, or isn't forwarded, and no one will tell you why.

Miss Betsy

[washmail]

I'm currently looking at a service from spamjadoo[dot]com

Their product appears to meet all related requirements and far, far more! Looks great...

I'm waiting for costing info which doesn't appear on their site, but they do offer a free 30 day trial period.

Does anyone want to offer an evaluation, advice etc.?