An idea: Unfortunately NDRs are somewhat of undefined that it's not a general solution, but why not block NDRs (only during rush hours) and whitelist NDRs containing the original header with some declude specific X-Header lines?
Markus > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Matthew Bramble > Sent: Saturday, January 03, 2004 6:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [Declude.JunkMail] Any thoughts on blocking > bounce messages from spam? spam? > > I think that Markus is mostly on the same page as I am on this issue. > > So far today, I have managed to catch 22 bounces from a Joe > Job on one customer's account that started late last night, > and this is only what my server caught due to the bounces > containing the original content that tripped my filters. The > previous one seems to have died down. The one that's going > on right now can be stopped by killing messages handled by > the nobody alias since this one uses a fake address on my > customer's domain. > > The issue with writing a filter for this is that it might be > very hard to just target undeliverable messages due to spam > is that it would probably be impossible to target just one > subset as opposed to all of it. I'm thinking that I should > write a filter for basically all bounces and virus > notifications, and upon request, use a ROUTETO action (or > whatever is appropriate) in the domain specific file, so that > these messages are delivered to a sub-directory to where we > are placing their held spam. > > I'm also definitely going to start redirecting unaddressable > stuff to a sub-directlry by default as several of these Joe > Jobs have used fake addresses, and that will take care of the problem. > > So the course of action will be: > > 1) Give a choice to redirect the nobody alias to a > sub-directory (for local accounts only). > 2) Give a choice to have a filter redirect system > generated messages to a sub-directory. > > I would prefer not to have to turn this stuff off and on on a > regular basis, so we'll see how receptive my clients are to this. > > Matt > > > > Markus Gufler wrote: > > >>my > >>customers are looking to me for a solution, imperfect as it > may be in > >>the end. I'm not by far sure about what to do. > >> > >> > > > >Matt, > > > >In this case maybe it's a solution to define a separated filter file > >(BLOCKBOUNCES) and put in this filter file as much bounce > error strings > >as you can find. Then if a customer asks you if it's > possible to block > >all this bounces you can explain him that this is possible, but this > >can also block "real" error messages. > > > >If your customer agree's you can create a per-user or per-domain > >junkmail file that does something with it. (add weight, > block, routeto, > >...) > > > >Maybe it would be an idea to create something between John's > Autowhite > >and Scott's Hijack: Hold any messages identified as NDR in a > separated > >user directory. Then requeue them only if there are not more then X > >such messages in a certain time range. This would allow > "regular" error > >reports going trough and dinamically filter all of them > during Joe-Job periods. > > > >Maybe a problem can occur if a customer sends out a large number of > >e-mails and there are several bounces. But if this happens I assume > >that the addresses was not aquired "regulary" ;-) > > > >Markus > > > > > > > > > --- > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.com)] > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be > found at http://www.mail-archive.com. > --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
