Kevin W. Gagel wrote: > ----- Original Message ----- > From: mouss <[EMAIL PROTECTED]> > To: > Cc: users@spamassassin.apache.org > Subject: Re: Duplicate header question > Date: Tue, 04 Dec 2007 23:47:21 +0100 > > >> Kevin W. Gagel wrote: >> >>> ----- Original Message ----- >>> >>> >>>> your amavisd-new is configured to reject mail with bad headers. as you >>>> see, this block legitimate mail. >>>> >>>> note that since your amavisd-new is sending bounces, you are a >>>> potential backscatter source. do not bounce mail after it was accepted >>>> by one of your servers. once mail is accepted, either deliver, >>>> quarantine or discard. discarding is bad, but bouncing is evil. >>>> >>>> >>> Backscatter is not just ANY bounced email. Non-delivery notices are not >>> bad either. >>> >>> >>> >> backscatter is when you send a bounce to someone who has not sent you >> mail. so unless you can guarantee (at least, to some extent) that the >> sender is whom you think, don't bounce: reject at smtp time or do >> something else. >> > > I know what backskcatter is, I was mearly pointing out contrary to your > assertion, backscatter is not ANY bounced email. I agree, if I didn't send, > I consider backscatter as well. > > While this is the preferred method, address verification is not always > advisable due to the large increase in queries that it can generate. I > don't worry to much about it myself because my site is not that burdened, > so I verify always. But - I have found a number of sites that verification > fails on because the outgoing server does not store the mail or accept mail > for their site. In those cases it's near impossible to do a quick > verification. Besides, RFC's require accepting the message... > > >>> A mail server sending a bounce notice because a message was malformed is >>> a correct action to take. >>> >> No: >> > > Yes! I did say "a correct" not THE correct. It is still A CORRECT action to > take. >
I still disagree, but I won't argue. >> 1- if you want to do this, then reject the message at SMTP time >> 2- If you think the message is legitimate, then accept it. smtp is not >> an educational channel. >> > > That has nothing to do with anything. If you have the resources to do smtp > proxy and hold connections open while your scanning the message that is > your perogative. Then don't be picky about malformed headers. > It is NOT a requirement. It is a prefered way of doing > things. > > It's not about requirements, it's about keeping mail usable. Again, there is no problem if you send few misdirected bounces from to time. but after a joe job, you'll start sending enormous quantities of misdirected bounces, and this is bad netiquette, and can't be justified by RFC conformance (unless you want to put pressure to make smtp obsolete). after all, open relay was ok some years ago. >>> Sending a bounce notice because the message was >>> infected has turned into a bad thing and is now considered backscatter. >>> >>> >> I have no problem with bounces to mail I _sent_. I have problems with >> bounces to mail I _never_ sent. and there is no difference between >> backscatter in the following cases: >> - recipients are not validated at smtp time >> - a filter thinks a message is infected or is spam >> - a filter thinks the message is malformed >> > > I agree, but the RFC's still say we should be sending out notices... > The RFC spirit is to avoid discarding mail. The RFC doesn't say to bounce mail because of malformed headers. Anyway, no RFC mandates accepting mail from outscatters. > >> bounces from mailing lists and because of disk quota or system problems >> is still acceptable, mostly because t doesn't happen to often. >> > > That depends on who your talking to. I've seen radical applications of > rejections because of an automated, ANY, automated message. > > The key for any good admin is to balance out the RFC's and what works best > for their company. While the RFC's are meant to keep all things working > well together, if we all follow them to the letter many sites would not > work because of minor errors on the part of their admins. (but then again, > that might not be a bad idea either!). >
