Explain this relay/spam attempt

[phil54]

Lo all,

just a quick question, if anyone can explain this to me that would be ace.

I'm just looking through the mail server logs and i find this relay/spam attempt, the bit i dont understand is the couple of lines in bold.

How is there no address in the sent mail field and why does the server accept this with a 250 ok?

I'm sure it's me being thick!

""RECEIVED: 220 smtp1.gruposantander.com ESMTP"""
""SENT: HELO xxxxxxxxx.co.uk"""
""RECEIVED: 250 smtp1.gruposantander.com"""
""SENT: MAIL FROM:<>"""
""RECEIVED: 250 sender <> ok"""
""SENT: RCPT TO:<rjygtu@abbey.co.uk>"""
""RECEIVED: 550 #5.1.0 Address rejected rjygtu@abbey.co.uk"""
""SENT: QUIT"""
""RECEIVED: 221 smtp1.gruposantander.com"""

""RECEIVED: 220 smtp1.gruposantander.com ESMTP"""
""SENT: HELO xxxxxxxxx.co.uk"""
""RECEIVED: 250 smtp1.gruposantander.com"""
""SENT: MAIL FROM:<>"""
""RECEIVED: 250 sender <> ok"""
""SENT: RCPT TO:<vqnpkc@abbey.co.uk>"""
""RECEIVED: 550 #5.1.0 Address rejected vqnpkc@abbey.co.uk"""
""SENT: QUIT"""
""RECEIVED: 221 smtp1.gruposantander.com"""

Thanks all

[dzekas]

Lo all,

just a quick question, if anyone can explain this to me that would be ace.

I'm just looking through the mail server logs and i find this relay/spam attempt, the bit i dont understand is the couple of lines in bold.

How is there no address in the sent mail field and why does the server accept this with a 250 ok?

I'm sure it's me being thick!

""RECEIVED: 220 smtp1.gruposantander.com ESMTP"""
""SENT: HELO xxxxxxxxx.co.uk"""
""RECEIVED: 250 smtp1.gruposantander.com"""
""SENT: MAIL FROM:<>"""
""RECEIVED: 250 sender <> ok"""
""SENT: RCPT TO:<rjygtu@abbey.co.uk>"""
""RECEIVED: 550 #5.1.0 Address rejected rjygtu@abbey.co.uk"""

Backscatter is not spam. @abbey.co.uk domain was used for return address in spam messages. See Joe Job article in Wikipedia. Undelivered messages are bouncing (SENT: MAIL FROM:<>, RFC821 "3.6. Relaying" chapter, paragraph about delivery failure and empty return path) back to abbey.co.uk domain mail exchangers.

smtp1.gruposantander.com is in same subnet as primary abbey.co.uk MX. So I assume that this server is one of abbey.co.uk domain MXs.

[phil54]

Ah right thanks dzekas, this is a new one for me.

I wonder why the spammer is targetting that particular domain?

[dzekas]

I wonder why the spammer is targetting that particular domain?

1. Lack of SPF records

2. Spammer wants to add credibility by using name of 6th UK bank.

3. Spammer is trying to scam Abbey clients. "Hello, this is Abbey support. Enter your login details here."

4. Spammer does not like bankers or mortgage providers or Abbey itself.

5. Spammer does not like sites that fail miserably when JavaScript is disabled.

[phil54]

I can see you've given this some thought dzekas lol

[redrummy]

Maybe a little TOO well... Hmm? Hmm?

[phil54]

Is there anyway of stopping this?

[dzekas]

Is there anyway of stopping this?

Send all mailer daemon bounces to some folder.

Check ips.backscatterer.org. Warning - high false positives rate.

Use SPF.

[phil54]

I already use spf on the mail server, is there anything else i can do bar that list?

[dzekas]

I already use spf on the mail server, is there anything else i can do bar that list?

backscatter is normal email traffic. If you try to block it, you will block normal traffic.

I think somebody on slashdot suggested adding custom headers to outgoing emails and then checking for those headers in all delivery status notifications.

[dzekas]

I already use spf on the mail server

Code: Select all

$ host -t txt abbey.co.uk
abbey.co.uk has no TXT record


[katip]

Is there anyway of stopping this?

You may use ASSP to manage this kind of crap.

[Claus von Wolfhausen]

Please note that ips.backscatterer.org has *NO FALSE POSITIVES* if it is used as intended.
If it does "False Positives" then there is *always* a problem in front of the computer.

What does ips.backscatterer.org list?
It lists systems sending backscatter or doing sender callouts.

What does this mean?
It means that almost every system listed will be (poorly configured) mailservers.
Therefore it is more than logic that you will loose lots of regular mails if you use it like a standard DNSBL.

The maintainers strongly suggest to use ips.backscatterer.org in SAFE MODE.
SAFE MODE means, that you will do querys if Envelope from is <> or postmaster only.

See here for more details: http://www.backscatterer.org/index.php?target=usage

Used in SAFE MODE you can not loose any mail, but it will protect you against misdirected bounces and abusive sender callouts.

[dzekas]

Please note that ips.backscatterer.org has *NO FALSE POSITIVES* if it is used as intended.
If it does "False Positives" then there is *always* a problem in front of the computer.

What does ips.backscatterer.org list?
It lists systems sending backscatter or doing sender callouts.

What does this mean?
It means that almost every system listed will be (poorly configured) mailservers.
Therefore it is more than logic that you will loose lots of regular mails if you use it like a standard DNSBL.

The maintainers strongly suggest to use ips.backscatterer.org in SAFE MODE.
SAFE MODE means, that you will do querys if Envelope from is <> or postmaster only.

See here for more details: http://www.backscatterer.org/index.php?target=usage

Used in SAFE MODE you can not loose any mail, but it will protect you against misdirected bounces and abusive sender callouts.

Sending DSN is not poor configuration. It is defined in SMTP rfc and all MXs that don't have access to user account information work that way. This includes secondary MX servers, qmail servers, user is overquota situations, etc.

If RBL or other filters block information about delivery failure, it is false positive.

[Claus von Wolfhausen]

Sending DSN is not poor configuration. It is defined in SMTP rfc and all MXs that don't have access to user account information work that way. This includes secondary MX servers, qmail servers, user is overquota situations, etc.
If RBL or other filters block information about delivery failure, it is false positive.

It is of course poor configuration to run an MX which does not know about its users.
Ok it is conform to rfc 2821, but running an open relay would also be conform too.
RFC's often don't cover the problem spam and things that happen when spammers are abusing the net.

So you should see that hiding behind rfc's is not always a good choice.
One should always use common sense too.

It should be no problem to install a userlist on a second mx and sync it from the primary if one really thinks that he still needs to have a secondary mx.
There are patches available for qmail too.
Overquota situaltions can also very easy be handled if one really wants to do so.

And lets say this very clear:
If a sysadmin has chosen to no longer accept bounces from systems which are known to be a source of backscatter then it is not false positives.

You might also be interested to read this:
http://spamlinks.net/prevent-secure-backscatter.htm

[Rainer]

Please note that ips.backscatterer.org has *NO FALSE POSITIVES* if it is used as intended.
If it does "False Positives" then there is *always* a problem in front of the computer.

What does ips.backscatterer.org list?
It lists systems sending backscatter or doing sender callouts.

What does this mean?
It means that almost every system listed will be (poorly configured) mailservers.
Therefore it is more than logic that you will loose lots of regular mails if you use it like a standard DNSBL.

The maintainers strongly suggest to use ips.backscatterer.org in SAFE MODE.
SAFE MODE means, that you will do querys if Envelope from is <> or postmaster only.

See here for more details: http://www.backscatterer.org/index.php?target=usage

Used in SAFE MODE you can not loose any mail, but it will protect you against misdirected bounces and abusive sender callouts.

Hello Claus, can you please tell me why listed the ip: 212.43.68.14?

Kind regards

[dzekas]

can you please tell me why listed the ip: 212.43.68.14?

UCEProtect Network listings are automatic. If address is listed in ips.backscatterer.org, it means that server accepted email and later sent bounce message to some spamtrap set by uceprotect network. Bounce message could contain delivery error, vacation notification or some automatic reply.

[dzekas]

Sending DSN is not poor configuration. It is defined in SMTP rfc and all MXs that don't have access to user account information work that way. This includes secondary MX servers, qmail servers, user is overquota situations, etc.
If RBL or other filters block information about delivery failure, it is false positive.

It is of course poor configuration to run an MX which does not know about its users.
Ok it is conform to rfc 2821, but running an open relay would also be conform too.
RFC's often don't cover the problem spam and things that happen when spammers are abusing the net.

So you should see that hiding behind rfc's is not always a good choice.
One should always use common sense too.

Basic software design is also part of common sense. SMTP server has no way of knowing about errors that occur in local delivery agent, because they can be triggered only in LDA. Email forwarder has no way of knowing that destination is not valid until it tries to deliver email to that destination.

You can find tools to reduce backscatter in simple setups, but you can't do that in any more complex email setup. List of safe mode configurations is limited to one email server and two commercial spam filtering solutions. Even in safe mode you will block all DSNs from blacklisted systems. Some of these DSNs can be triggered by normal user actions and blocking them is false positive.

Several years ago people complained about TMDA traffic. Now amount of email abuse by spammers reached the level when people are complaining about DSNs.

[Claus von Wolfhausen]

Hello Claus, can you please tell me why listed the ip: 212.43.68.14?

Kind regards

Last "Impact" was 2 nd Mai 2008 19:54 German time
Searching the smtplog of that time and date you should find somthing like:

Access denied and blocklisted

That was the event that got your IP listed.

[Claus von Wolfhausen]

Basic software design is also part of common sense. SMTP server has no way of knowing about errors that occur in local delivery agent, because they can be triggered only in LDA. Email forwarder has no way of knowing that destination is not valid until it tries to deliver email to that destination.

Oh it is possible that a forwarder knows if destination exists by probing the recipients mail system before accepting (recipient callout) and different to sender callouts it is not considered abusive because it will not harm or waste 3 rd parties resources.

You can find tools to reduce backscatter in simple setups, but you can't do that in any more complex email setup. List of safe mode configurations is limited to one email server and two commercial spam filtering solutions. Even in safe mode you will block all DSNs from blacklisted systems. Some of these DSNs can be triggered by normal user actions and blocking them is false positive.

The list with usage SAFE MODE example covers only what we were able to test or which we got reported to work.
You can assume it will be possible with other software too and if not then simply request your vendor to implement that feature in the next release.
Yes you are right that also in SAFE MODE all DSN's from listed systems will be blocked, but that seems to be acceptable to prevent your users get flooded with DSN's they are not responsible for. It is hardly a false positive - it is more like a decision from the system admin.

Several years ago people complained about TMDA traffic. Now amount of email abuse by spammers reached the level when people are complaining about DSNs.

TMDA was *ALWAYS* a broken idea. Tell me what you would suggest to do while beeing flooded with DSN's?
Accepting that your users get flooded with bounces they didn't originate? Bad idea.
Blocking all DSN's from everywhere? That's a much worse idea.
Before doing so it is much better to just block DSN's from systems listed at ips.backscatterer.org
Last one is acceptable at least for me until someon comes up with a better idea.

[dzekas]

Tell me what you would suggest to do while beeing flooded with DSN's?
Accepting that your users get flooded with bounces they didn't originate? Bad idea.
Blocking all DSN's from everywhere? That's a much worse idea.
Before doing so it is much better to just block DSN's from systems listed at ips.backscatterer.org
Last one is acceptable at least for me until someon comes up with a better idea.

I am not saying that backscatterer.org blacklist is bad. I might even use it in order to reduce amount of bounces reaching end users. If I use it, I do understand that sending DSN is not unusual and RBL can block normal servers. That's why I recommend ips RBL here and I warn users about false positives in my recommendation.

I use qmail and I still remember similar "bad server" argument between qmail and spamcop. Qmail design is not broken. It only has higher DSN ratio than other servers.

I could have written whole lecture about backscatter, but I chose to give short answer and it seems that you took it personally.

If you defend some project on third party forum, you might also disclose that you are part of that project.

[Rainer]

Hello Claus, can you please tell me why listed the ip: 212.43.68.14?

Kind regards

Last "Impact" was 2 nd Mai 2008 19:54 German time
Searching the smtplog of that time and date you should find somthing like:

Access denied and blocklisted

That was the event that got your IP listed.

Hello Claus, thx for answering!

That is not what i want to know. I'm not the owner of this ip, but i know this ip is very serious and i dont unterstand the exist of the ip in the blacklist.
You can send a private-msg to me (auch gerne in Deutsch!

Kind regards

[tomdatkins]

Claus von Wolfhausen
UCEprotect.

These guys are criminals. There is no differance between these guys and the spammers. They should be shutdown and removed any RBl list you use.

They have no interest in stopping spam just blackmailing people for money.

DO NOT USE THAT RBL, and help spread the word on these criminals.