Re: Handling mail from mailer daemons

From: Alessandro Vesely <>
Date: Fri, 08 Oct 2010 13:36:05 +0200

On 08/Oct/10 07:45, Murray S. Kucherawy wrote:
> On Fri, 8 Oct 2010, Alessandro Vesely wrote:
>>> In fact MTA 2 would have signed the DSN, except that DSNs are not
>>> passed through signing filters by MTA 2 by design, so its DSNs will
>>> never be signed.
>> Why? I don't understand the rationale for such design.
> DSNs are generated internally; they don't arrive via SMTP, and the
> SMTP handling code is where the filter hooks are.

When rejections are issued by a handler, it is possible to invoke an
external program or script instead of passing a simpler piece of data,
in order to deliver notifications with the desired header. Rejections
on relaying can be controlled only marginally, IME. But then the
resulting DSNs should be already "inside", in the sense that no
independent verifier is supposed to handle them.

>> This is yet another failure point for ADSP. However, they could have
>> set up a sub-domain for sending those bounces "From".
> I think that requires MTA awareness of ADSP and thus would be a hard
> sell.

OTOH, does it make sense to assert "all" or "discardable" without
being aware of it? If we conceive ADSP as a super-secure framework
for transactional mail only, the less domains assert it, the more it
can be enforced.

IMHO, a note on properly configuring the "From" field for DSNs should
be added to ADSP specs. (And the phrase /Independent Users/ in
Appendix B5 could be substituted with /Human Users/, after considering
unalienable rights :-)

> This is definitely a setting to accomodate MTA design, not a statement
> about how ADSP should've been written in the first place. That said,
> I'm wondering if it's a good idea.

To allow "From:" when the return-path is empty,
would defeat configured ADSPActions. IMHO, it may be more meaningful
to distinguish "all" from "discardable" than deciding deliverability
based on the return-path.
Received on Fri Oct 08 2010 - 15:20:42 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:49 PST