avoid bouncing of rejected messages
in [Sendmail]
|
From: Henning Hucke on 15 Feb 2010 03:58 On Fri, 12 Feb 2010, Dietmar Rieder wrote: > Hi, Hello Dietmar, > is there a way to avoid bouncing of rejected messages? bouncing is the RFC way if messages are rejected. Discarding them is a RFC violation. At least in germany you can be legally held responsible if you discard false positives with enough relevancy for the intended recipient. I guess that it's the same in Austria. Image somebody sends a contract offer which is for some reason rated as spam and rejected. You would discard this rejection and the sender never gets the information that his mail didn't reach its destination while he could have taken counter measures (for instance calling the intended recipient) in case he would have received the bounce. It's usually - as your example spotlights once again - a bad idea to run anti spam measurements behind anti spam measurements. > [...] Regards Henning Hucke -- Honesty is for the most part less profitable than dishonesty. -- Plato
From: Dietmar Rieder on 15 Feb 2010 04:06 On 02/13/2010 09:12 PM, David F. Skoll wrote: > Dietmar Rieder wrote: > >> At the MX, we are using several anti-Spam techniques that reject >> messages based on different rules and Spam that passes that rules gets >> tagged but we (legally) have to forward it to the downstream servers. >> But, unfortunately some of our downstream server use Spam-fighting tools >> to reject spammy messages, which in turn leads to a bounce generation at >> our MX. > > Your downstream users should be told to discard (rather than > reject) spam if it originates from your relay machine. If they > refuse, then they are deliberately causing you problems > and should be cut off. Yeah, that's what we did. However, it is something that is not done automagically ;-) > > [Our commercial anti-spam solution has the notion of a > "friendly network" and it can be told to discard rather than > bounce for unwanted content arriving from a friendly network.] One problem with discarding is, that in case of a false positive the sender will not notice that the message did not reach the recipient. We are using MIMEDefang, so one thing I was thinking of, was to change the return-path (envelop sender) to a local quarantine address in case our MX is tagging a message as SPAM, but this might also cause more problems than it would help. Didi
From: Dietmar Rieder on 15 Feb 2010 04:15 On 02/12/2010 09:39 PM, D. Stussy wrote: > "Dietmar Rieder"<nospam(a)tugraz.at> wrote in message > news:4b754d12$0$11352$3b214f66(a)aconews.univie.ac.at... >> On 02/12/2010 11:41 AM, Xavier Roche wrote: >>> Dietmar Rieder wrote: >>>> At the MX, we are using several anti-Spam techniques that reject >>>> messages based on different rules and Spam that passes that rules gets >>>> tagged but we (legally) have to forward it to the downstream servers. >>> >>> Why ? If you reject the spam during the SMTP transaction, you refuse to >>> take the responsibility of the delivery. It is up to the sender to >>> ensure that the original sender knows that his message was not > delivered. >>> >>> You do not "delete" nor "bounce" the message in this situation: you > just >>> do not want to take it. This clears any responsibility, including risks >>> of bounding a message to an innocent recipient whose email address was >>> forged. >>> >>>> But, unfortunately some of our downstream server use Spam-fighting > tools >>>> to reject spammy messages, which in turn leads to a bounce generation > at >>>> our MX. >>> >>> You choose to get the "hot potato", and you are screwed. Do not take > it. >> >> Well, that's easy to say but not always doable, it's not us to decide >> what to reject and what not, if the message is "technically" ok and >> passed the filters (nolisting, greylisting, reverse lookups,....) >> imposed on the MX. We cannot reject messages based on its content. >> Maybe one can do that on a private server but unfortunately not in our >> environment. > > A solution for your problem was posted last year on this group, and > rejected by consensus. > > You need to modify your server to read the actual extended code returned > (e.g. 5.7.1), and if it's on a particular list, drop the message instead of > generating the NDR bounce message. Ok, thanks. I'll search for the discussion, or do you have a link? Didi
From: Dietmar Rieder on 15 Feb 2010 05:29 On 02/15/2010 09:58 AM, Henning Hucke wrote: > On Fri, 12 Feb 2010, Dietmar Rieder wrote: > >> Hi, > > Hello Dietmar, > >> is there a way to avoid bouncing of rejected messages? > > bouncing is the RFC way if messages are rejected. Discarding them is a > RFC violation. > At least in germany you can be legally held responsible if you discard > false positives with enough relevancy for the intended recipient. I > guess that it's the same in Austria. Exaclty, that's what I wrote in reply to David's comment. One possibility would be to quarantine such bounces. And then decide which to release and which not. > Image somebody sends a contract offer which is for some reason rated as > spam and rejected. You would discard this rejection and the sender never > gets the information that his mail didn't reach its destination while he > could have taken counter measures (for instance calling the intended > recipient) in case he would have received the bounce. > > It's usually - as your example spotlights once again - a bad idea to run > anti spam measurements behind anti spam measurements. Unfortunately it is not our decision what to run on a downstream server... But I think the only practicable solution is, talk to the persons responsible for the downstream server, and tell them not to reject but to quarantine. Thanks Didi
From: Loki Harfagr on 15 Feb 2010 06:04 Mon, 15 Feb 2010 10:15:27 +0100, Dietmar Rieder did cat : > On 02/12/2010 09:39 PM, D. Stussy wrote: >> "Dietmar Rieder"<nospam(a)tugraz.at> wrote in message >> news:4b754d12$0$11352$3b214f66(a)aconews.univie.ac.at... >>> On 02/12/2010 11:41 AM, Xavier Roche wrote: >>>> Dietmar Rieder wrote: >>>>> At the MX, we are using several anti-Spam techniques that reject >>>>> messages based on different rules and Spam that passes that rules >>>>> gets tagged but we (legally) have to forward it to the downstream >>>>> servers. >>>> >>>> Why ? If you reject the spam during the SMTP transaction, you refuse >>>> to take the responsibility of the delivery. It is up to the sender to >>>> ensure that the original sender knows that his message was not >> delivered. >>>> >>>> You do not "delete" nor "bounce" the message in this situation: you >> just >>>> do not want to take it. This clears any responsibility, including >>>> risks of bounding a message to an innocent recipient whose email >>>> address was forged. >>>> >>>>> But, unfortunately some of our downstream server use Spam-fighting >> tools >>>>> to reject spammy messages, which in turn leads to a bounce >>>>> generation >> at >>>>> our MX. >>>> >>>> You choose to get the "hot potato", and you are screwed. Do not take >> it. >>> >>> Well, that's easy to say but not always doable, it's not us to decide >>> what to reject and what not, if the message is "technically" ok and >>> passed the filters (nolisting, greylisting, reverse lookups,....) >>> imposed on the MX. We cannot reject messages based on its content. >>> Maybe one can do that on a private server but unfortunately not in our >>> environment. >> >> A solution for your problem was posted last year on this group, and >> rejected by consensus. >> >> You need to modify your server to read the actual extended code >> returned (e.g. 5.7.1), and if it's on a particular list, drop the >> message instead of generating the NDR bounce message. > > Ok, thanks. I'll search for the discussion, or do you have a link? http://groups.google.com/group/comp.mail.sendmail/browse_frm/thread/75ef5cac6f3f6c78/1e327e9a11a5114c?#1e327e9a11a5114c
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: stat=Need RCPT ? Next: Accept or Forward mail based on source |