On Wed, Dec 22, 2010 at 05:06:03PM +0100, lst_ho...@kwsoft.de wrote:
> For a long time i also prayed "if you don't get a error all is fine".
> Unfortunately this is more and more not the case. After repeatedly
> disapearing mail in some content filters it was decided to try some more
> "modern" concept like DSN. So we set DSN for all outgoing mail (corporate
> environment). A system was setup which parses DSN reply and set a *visible*
> status for outgoing mail according to RFCs. As one can't demand something
> one is not willing to provide we like to *fully* honor DSN requests from
> clients.
This is an over-earnest mistake I think. You are not "demanding" DSN
notices from clients. Rather, you providing your internal senders with
best effort notice of email delivery to the recipient.
In my case, not only do I not offer "DSN" in EHLO responses for inbound
email, I also ignore "DSN" from remote servers in outbound traffic. Thus,
(SUCCESS) DSN always tells my internal senders that mail has left our
systems and is now the responsibility of the recipient's systems, and
conversely remote senders know (from their own servers) that we took
ownership of the mail.
End-to-end DSN may do more harm than good...
> If we accept a mail at the border it will be delivered anyway to the user
> mailbox so sending out a "delivered" DSN status on request is no more
> disclosure anyway i guess.
I would recommend that you go further, and not advertise "DSN" in your
inbound MTAs, and likewise ignore DSN in remote MTAs. Use DSN as a
purely internal mechanism that informs senders that mail was accepted
by the remote organization, with the notice always sent by the sender's
outbound border MTA.
--
Viktor.
