[selowitch]

I keep getting spurious notifications of delivery failure for messages I didn't send. Some of them are spoofing my domain, others spoof my whole e-mail address, but most spoof nothing but somehow are directed to me. It is so annoying!! Is there any way to reduce the number of these things? I don't want to filter them out because I want to make sure I see any legitimate ones.

[Person Man]

Originally Posted by selowitch 

I keep getting spurious notifications of delivery failure for messages I didn't send. Some of them are spoofing my domain, other spoof my whole e-mail address, but most spoof nothing but somehow are directed to me. It is so annoying!! Is there any way to reduce the number of these things? I don't want to filter them out because I want to make sure I see any legitimate ones.

Nope.

Your e-mail address was put as the originating address of some spam that was sent out, so for each e-mail that bounces, you're going to get a delivery failure notification.

It's called a Joe Job.

Sucks. All you can do is wait it out, really.

[Doofy]

Maybe, depending on your setup:

Filter out all bounces which don't include some reference to your domain in the bounced message ID.

i.e. All of your outgoing messages might have "selowitch.com" at the end of the message ID and all legit bounces will probably reference that ID.

YMMV

[selowitch]

Thanks to both for your replies. Very interesting! I could enable Sender Policy Framework (SPF) on one of my domains, but I think that might create more problems than it solves. I think I may try filtering for now and then just wait it out.

It's really cool that I got two very helpful responses in a matter of minutes. Gotta love MacNN!

EDIT: Oh, drat. Looks like Mozilla Thunderbird doesn't support negatively phrased filters on custom filters such as one for Message-Id; in other words, I can't filter for messages that "do not contain" my domain in the Message-Id header. Darn.

[Goldfinger]

I had it happen once. After a week or two it stopped.

[Person Man]

Originally Posted by Goldfinger 

I had it happen once. After a week or two it stopped.

It happened to me, too. Took about 7 to 10 days for it to die out completely.

[Opera Man]

I started receiving these failure notices, always addressed to a random 3 or 4 letters @mydomain, on January 1, and they are continuing to come in at a rate of 6-12 each day. The wikipedia entry linked to from an earlier posting - joe jobs - suggested that this may be malicious activity by someone who wants to discredit my site as a spammer. Anybody got views/experience on this?

[Person Man]

Originally Posted by Opera Man 

I started receiving these failure notices, always addressed to a random 3 or 4 letters @mydomain, on January 1, and they are continuing to come in at a rate of 6-12 each day. The wikipedia entry linked to from an earlier posting - joe jobs - suggested that this may be malicious activity by someone who wants to discredit my site as a spammer. Anybody got views/experience on this?

Probably not. It's more likely that someone is using your domain as a target for all the bounced spam. Nothing malicious other than the fact that it's highly annoying to you.

[besson3c]

Originally Posted by Doofy 

Maybe, depending on your setup:

Filter out all bounces which don't include some reference to your domain in the bounced message ID.

i.e. All of your outgoing messages might have "selowitch.com" at the end of the message ID and all legit bounces will probably reference that ID.

YMMV

Do you mean filter based on envelope information, as opposed to headers?

[Doofy]

Originally Posted by besson3c 

Do you mean filter based on envelope information, as opposed to headers?

Do it anywhere you want.

[besson3c]

Originally Posted by Doofy 

Do it anywhere you want.

Won't work on headers, because they are forged. It will only work on envelope information.

[Doofy]

Originally Posted by besson3c 

Won't work on headers, because they are forged. It will only work on envelope information.

Bessie, I really think you need to re-read the thread and see what we're trying to accomplish here.

[besson3c]

Originally Posted by Doofy 

Bessie, I really think you need to re-read the thread and see what we're trying to accomplish here.

Deal with bounces being created from a Joe job attack. Do you understand what a Joe job is?

[Doofy]

Originally Posted by besson3c 

Deal with bounces being created from a Joe job attack. Do you understand what a Joe job is?

This ain't a joe job - it's backscatter*.

Now, go think about what genuine bounces have and what fake bounces don't have. That's all you have to do - differentiate between the real and the fake then null the fake.


(*hey, guess what Bessie - my real name's in the manual to that server. ).

[besson3c]

Originally Posted by Doofy 

This ain't a joe job - it's backscatter*.

Now, go think about what genuine bounces have and what fake bounces don't have. That's all you have to do - differentiate between the real and the fake then null the fake.


(*hey, guess what Bessie - my real name's in the manual to that server. ).

So, a Joe Job is usually done to harm a particular person, a backscatter is the side effect of a spammer, but the basic operation is the same: forging of a user's address, and bounce messages sent back to the forged user.

The way forgeries happen is by forging the headers of an email. The envelope information can *not* be altered, but forging the headers of an email is actually trivial. Therefore, filtering based on email headers will be a fruitless venture.

Did you help write mailtraq?

[Doofy]

Originally Posted by besson3c 

The way forgeries happen is by forging the headers of an email. The envelope information can *not* be altered, but forging the headers of an email is actually trivial. Therefore, filtering based on email headers will be a fruitless venture.

If it's a valid bounce message, then it'll contain a valid reference. If it's a fake then the chances of it containing that valid reference will be almost zero.

Of course, it all depends on how you have your outgoing email configured. If it's set to deliver a message ID containing the keyword "boobies" so that your outgoing message ID on every message is something like hajusisjs78jnsisjs748boobies@domain.com then every incoming bounce message which doesn't contain *boobies@domain.com is probably a fake so can be safely nulled. Spammers might be able to fake your domain but unless you've actually had email contact with them they'd have no idea about the keyword.

Even without the ability to get into your outgoing message-IDs, you could easily add an "X-Identifier" header to your outgoing messages and filter on returned undeliverable without that header reference.

i.e. IF subject contains "undeliverable" AND body DOES NOT contain "X-Identifier: boobies" THEN discard.

Doing that actually got me out of a sticky situation once - overly-jumpy victim of forged spam with my domain on it got the ISPs involved. Easy job to persuade the ISP that if the message had genuinely been from me it would have had certain unique characteristics.

Originally Posted by besson3c 

Did you help write mailtraq?

I was in the initial development group.

[besson3c]

Originally Posted by Doofy 

If it's a valid bounce message, then it'll contain a valid reference. If it's a fake then the chances of it containing that valid reference will be almost zero.

Of course, it all depends on how you have your outgoing email configured. If it's set to deliver a message ID containing the keyword "boobies" so that your outgoing message ID on every message is something like hajusisjs78jnsisjs748boobies@domain.com then every incoming bounce message which doesn't contain *boobies@domain.com is probably a fake so can be safely nulled. Spammers might be able to fake your domain but unless you've actually had email contact with them they'd have no idea about the keyword.

Even without the ability to get into your outgoing message-IDs, you could easily add an "X-Identifier" header to your outgoing messages and filter on returned undeliverable without that header reference.

i.e. IF subject contains "undeliverable" AND body DOES NOT contain "X-Identifier: boobies" THEN discard.

Doing that actually got me out of a sticky situation once - overly-jumpy victim of forged spam with my domain on it got the ISPs involved. Easy job to persuade the ISP that if the message had genuinely been from me it would have had certain unique characteristics.



I was in the initial development group.

Hey Doofy,

Very interesting approach and strategy there! I guess I was misunderstanding you earlier, but you should have said that you need to own the relays for this to work

We actually do in our setup, and if it weren't so expensive to setup sieve rules for all of our users to filter based on this custom string (and to append this string to all outgoing emails), we'd probably do something like this. Maybe we should re-explore this possibility though, so I thank you for this idea!

[Doofy]

Originally Posted by besson3c 

Very interesting approach and strategy there! I guess I was misunderstanding you earlier, but you should have said that you need to own the relays for this to work

You could also get it to work if you use an email client capable of putting additional headers into messages by default.

Originally Posted by besson3c 

We actually do in our setup, and if it weren't so expensive to setup sieve rules for all of our users to filter based on this custom string, we'd probably do something like this.

You haven't got a global ruleset? Get yerself a copy of CommuniGate Pro - takes about two minutes to sort it with that.

Originally Posted by besson3c 

Maybe we should re-explore this possibility though, so I thank you for this idea!

No worries.

[besson3c]

Originally Posted by Doofy 

You could also get it to work if you use an email client capable of putting additional headers into messages by default.

Yeah, but this would only work if we could each of our 120,000 users to do this, ain't gonna happen.

You haven't got a global ruleset? Get yerself a copy of CommuniGate Pro - takes about two minutes to sort it with that.

Creating sieve rules is a piece of cake, we already do that, it's simply an issue of scalability since our user base is so high and our resources limited (esp. by the end of the life cycle of our servers). We get literally 2.5 million or so spam messages a day.

[besson3c]

Doofy: what do you do about accommodating the fact that different MTAs have different bounce messages? Were you just scanning the body of a message for an SMTP code?

[Doofy]

Originally Posted by besson3c 

Yeah, but this would only work if we could each of our 120,000 users to do this, ain't gonna happen.

Creating sieve rules is a piece of cake, we already do that, it's simply an issue of scalability since our user base is so high and our resources limited (esp. by the end of the life cycle of our servers). We get literally 2.5 million or so spam messages a day.

Ahhh. Small ISP scenario? Perhaps this idea wouldn't be too good for you then - I was aiming it more at the end user and small company type folks.

Still, your users have the option of doing it client side if they want to (or can be bothered to) without it hitting your server resources. Just pop the instructions onto your web or something (if you want to) - let the client decide.

Originally Posted by besson3c 

Doofy: what do you do about accommodating the fact that different MTAs have different bounce messages? Were you just scanning the body of a message for an SMTP code?

Yep. Most MTAs will at least give the full headers of the bounce so it's mostly good. It's not a 100% perfect method but it'll kill the majority of backscatter (obviously won't rescue reputation from a well-executed joe job, but it'll free up the inbox).

If only people would turn their rDNS lookups on... ...ho hum.

[besson3c]

Originally Posted by Doofy 

Ahhh. Small ISP scenario? Perhaps this idea wouldn't be too good for you then - I was aiming it more at the end user and small company type folks.

Still, your users have the option of doing it client side if they want to (or can be bothered to) without it hitting your server resources. Just pop the instructions onto your web or something (if you want to) - let the client decide.

Yeah, client side seems like the way to go, except for the fact that in some cases these headers might be obliterated by various MTAs, and scanning message bodies for SMTP codes if the MTA does follow RFCs (as many don't) becomes increasingly complex. However, like you said, it should work in many, if not most circumstances.