>-----Message d'origine----- >De : [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] la part de Hal Dell >Envoy=E9 : mercredi 3 octobre 2007 18:10 >=C0 : [email protected] >Objet : [xmail] Re: Bounced eMail messags > > > >> 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=20 >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=20 >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=20 >so that it does >not send all the bounced email >> messages. I realise this may not conform to the RFC's and I=20 >realise that >not many people may use it, but >> it would still be a very helpful if the mail-admin found=20 >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=20 >SERIOUS problem. >All of this started with us back >in July. The problem comes and goes. [NB: NDR =3D ?] > >However, the issue now is I'm getting complaints from the=20 >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=20 >"bogon" user >for said domain and set >the alias to a '*' then set the disk quota 1K. So this first=20 >captures all of >the bogus eMails for a domain >and once the quota reaches 1K an error should be sent back=20 >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=20 >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=20 >would send the >bounce back to their user instead of us. > >As I understand it, if the sending MTA gets a 4XX Reply code, =20 >the response >code is considered to be a transient >Error and the sender's MTA is responsible for the queuing of=20 >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. > > >
Use glst (greylisting) :) Allmost 99% of these bad connexions will be elliminated, as 99% will = never retry. And as glst will first response with a 4xx code, no NDR until second = attempt connexion accepted by glst. PS : NDR =3D ? -> Not Deliverable Report (if I remember correctly) Francis - 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]
