> Wolfy Wrote @ Wednesday, October 03, 2007 10:37 AM > > Last weekend I had an example of this happen to one of my backup mail servers. > When I noticed the problem there were 27,000 NDR type messages it was trying to deliver. > > Mostly all were sent to random [EMAIL PROTECTED] and the mail server was diligently trying sending > NDR's to every single one of them - most likely to faked or spoofed addresses. > > I could actually sit and watch more junk flooding in, they appeared to be coming from many compromised > hosts so blocking the IP's didn't really help. > > So it would be very useful if Xmail at least had an option so that it does not send all the bounced email > messages. I realise this may not conform to the RFC's and I realise that not many people may use it, but > it would still be a very helpful if the mail-admin found that NDR messages were getting out of hand. > > One or two legitimate senders may not know that their mail was not delivered, but when compared to the > type of flood described here its a small price to pay
Yes, you are absolutely correct -- this is becoming a very SERIOUS problem. All of this started with us back in July. The problem comes and goes. [NB: NDR = ?] However, the issue now is I'm getting complaints from the folks getting the bounce backs because a lot of time the from line in header is forged and points to a real eMail Address. I'm also getting complaints from the targets of the effective SYN Flooding. What I started to do is test this work around idea -- create a "bogon" user for said domain and set the alias to a '*' then set the disk quota 1K. So this first captures all of the bogus eMails for a domain and once the quota reaches 1K an error should be sent back indicating the mailbox is full. The problem is that xMail still generates a bounce back eMail message ! Now, I'm not an SMTP RFC expert, however, if xMail would simply reply "452 Requested action not taken: insufficient system storage" instead of accepting the eMail we would be fine. Let the sender deal with the error. If it was a legitimate sender the sender's MTA would send the bounce back to their user instead of us. As I understand it, if the sending MTA gets a 4XX Reply code, the response code is considered to be a transient Error and the sender's MTA is responsible for the queuing of the eMail and trying again. The middle digit in the 452 error code, in other words -- 5 indicates, the problem is with the destination MTA. If sure someone on the list knows this RFC stuff better and can offer another solution that is more RFC compatible. It think we need to get this NDR problem solved quick... Thanks, Hal Dell Managing Partner ePodWorks.net, Inc. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
