ricbax
asked on
Qmail ... NDR and RNDR
Recently my server has started to receive what I believe to be RNDR (reverse non-delivery reports) which is a tactic that spammers use to get their junk read. I need to find some kind of solutions soon before It gets too out of hand. I am looking for either an open source script or program that handles RNDR.
TIA
-ricbax
TIA
-ricbax
ASKER
Reverse Non-Delivery Reports
I know what a NDR is. I don't get the "reverse" part of it.
A NDR is a mail generated by a MTA on failure to deliver to the next hop. This comes in with a sender of <> and is usually shown in clients by MAILER-DAEMON or equivalent.
Or do you mean you are getting Joejob'ed and getting hit by backscatter? There isn't a good solution to deal with backscatter at the moment.
For small operations, it may be feasible to track every mail you are sending out, and then accept bounces only for those hosts.
You may want to use rblsmtpd and rbldnsd to find the hosts sending you bounces and blacklist them until the joe-job goes away.
If this is a rare occurence, or the spam volume is too high, rejecting the null sender might be an option (not recommended, but sometimes this is the only thing that works).
A NDR is a mail generated by a MTA on failure to deliver to the next hop. This comes in with a sender of <> and is usually shown in clients by MAILER-DAEMON or equivalent.
Or do you mean you are getting Joejob'ed and getting hit by backscatter? There isn't a good solution to deal with backscatter at the moment.
For small operations, it may be feasible to track every mail you are sending out, and then accept bounces only for those hosts.
You may want to use rblsmtpd and rbldnsd to find the hosts sending you bounces and blacklist them until the joe-job goes away.
If this is a rare occurence, or the spam volume is too high, rejecting the null sender might be an option (not recommended, but sometimes this is the only thing that works).
ASKER
I am currently looking into the following for a solution: http://www.openspf.org/
Here is information on what R-NDRs are:
In spite of your efforts to prevent direct attempts to relay mail, we continue to see spammers circumvent what you have done. They take advantage of the fact that most mail systems will attempt to send a non-delivery report (NDR) when a message cannot be delivered as addressed, and returning the original message contents.
Specifically the details are as follows:
1.
A spam message is created with ...
1.
the intended spam victim's address placed in the sender field, and
2.
a random and fictitious recipient at your domain
2.
Thousands of such messages are sent to your mail server.
3.
Your mail server determines that each message cannot be delivered and starts to send NDR email messages back to what appears to be the sender of the original message, i.e. the spam victim.
While it is true that this is an indirect method since the first part of the message contains a non-delivery report, the spam contents are carried intact to the receiving spam victim. Even worse, there is an increased probability that the spam victim will read the message thinking that it is a non-delivery report for email he or she actually sent.
The end result is the spammer has attained a new form of mail relaying. Like the direct approach, it is not the spammer's own mail server that delivers the junk email, but yours. Once again, your server's resources are being stolen to deliver spam.
CMS calls this a "Reverse NDR" attack. Many of our larger customers have experienced this, some so badly that 33% or more of the Internet messages are attributed to this attack. In one extreme case, more than 99% of the 100+ million messages received per day is this spam attack.
Here are some symptoms when you are under Reverse NDR attack:
1.
Your mail server repeatedly gets on one or more DNS Black Lists
2.
Sluggish email delivery
3.
Outbound queues full of non-delivery notices
4.
As soon as the outbound queue is cleared, more entries appear upon refreshing the view
5.
Excessive administrator time (hours) to clear outbound queues
Here is information on what R-NDRs are:
In spite of your efforts to prevent direct attempts to relay mail, we continue to see spammers circumvent what you have done. They take advantage of the fact that most mail systems will attempt to send a non-delivery report (NDR) when a message cannot be delivered as addressed, and returning the original message contents.
Specifically the details are as follows:
1.
A spam message is created with ...
1.
the intended spam victim's address placed in the sender field, and
2.
a random and fictitious recipient at your domain
2.
Thousands of such messages are sent to your mail server.
3.
Your mail server determines that each message cannot be delivered and starts to send NDR email messages back to what appears to be the sender of the original message, i.e. the spam victim.
While it is true that this is an indirect method since the first part of the message contains a non-delivery report, the spam contents are carried intact to the receiving spam victim. Even worse, there is an increased probability that the spam victim will read the message thinking that it is a non-delivery report for email he or she actually sent.
The end result is the spammer has attained a new form of mail relaying. Like the direct approach, it is not the spammer's own mail server that delivers the junk email, but yours. Once again, your server's resources are being stolen to deliver spam.
CMS calls this a "Reverse NDR" attack. Many of our larger customers have experienced this, some so badly that 33% or more of the Internet messages are attributed to this attack. In one extreme case, more than 99% of the 100+ million messages received per day is this spam attack.
Here are some symptoms when you are under Reverse NDR attack:
1.
Your mail server repeatedly gets on one or more DNS Black Lists
2.
Sluggish email delivery
3.
Outbound queues full of non-delivery notices
4.
As soon as the outbound queue is cleared, more entries appear upon refreshing the view
5.
Excessive administrator time (hours) to clear outbound queues
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
So I would just apply the patches directly to the folder where my qmail installation is and I am good to go?
Patch, compile, install and you should be good to go. That link I gave you points to multiple patches, so you might want to take a closer look at that.
(IMO, running stock qmail on today's Internet is a bad idea. Postfix or Exim might be easier, and even Sendmail is better. Disclaimer: I have ~ 5 years of Postfix experience, and I work for a fairly large email provider where Postfix is handling millions of messages per hour.),
(IMO, running stock qmail on today's Internet is a bad idea. Postfix or Exim might be easier, and even Sendmail is better. Disclaimer: I have ~ 5 years of Postfix experience, and I work for a fairly large email provider where Postfix is handling millions of messages per hour.),
ASKER
Well it is not completely stock qmail, but after 2 years of using my current config this RNDR or backscatter/outscatter as you call it, started cropping up. The patches that you recommend, after thoroughly reading it does not work well apparently because vpopmail is being used.
ASKER
Well I have decided to use this solution ... which I came across through your set of links:
http://qmail.jms1.net/patches/validrcptto.cdb.shtml
Thanks for the help!
ricbax
http://qmail.jms1.net/patches/validrcptto.cdb.shtml
Thanks for the help!
ricbax
Perhaps you should look at qpsmtpd?
http://smtpd.develooper.com/