Prev: Cheap Wholesale Soccer Shoes www.jordanonline06.com (paypal payment)
Next: Help! need to write a rule....only allow send mail to a specific account
From: Michael on 17 Mar 2010 21:30

"Loki Harfagr" <l0k1(a)thedarkdesign.free.fr.INVALID> wrote in message
news:4b792a4d$0$21823$426a74cc(a)news.free.fr...
> 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

I've read that discussion and the premise of the writer about some of the
RFC's is in error.
Yes, the RFC's say that under "certain" circumstances a DSN should be
generated but specifically, RFC2476 says
the if the return path is not verifiable, then the message should be
immediately rejected so that there is no possibility of a misdirected NDR.

The directive in RFC2821 says that "undeliverable mail" notification must be
sent to the "originator" of the undeliverable mail. Note that the
requirement is to send the notice to the "originator", not the proported
originator and not the bogus or forged (From or Replyto) originator.

If the reverse path has been lost because the message has been store and now
must be relayed or bounced, the the NDR must not be sent because if violates
the above requirements as outlined in the RFC's. Since the return path can
not be trusted, a mail system must not be configured to send NDR's but
instead must reject the message at the point of connection.

Michael





 | 
Pages: 1
Prev: Cheap Wholesale Soccer Shoes www.jordanonline06.com (paypal payment)
Next: Help! need to write a rule....only allow send mail to a specific account