From: Boring, Andrew (no email)
Date: Tue Jun 01 2004 - 09:46:27 EDT
Greg A. Woods wrote:
> Hmmm....
>
> Somehow or another I don't think RFC 2852 (DELIVERBY) ever
> entered this
> conversation.
Nope. I wasn't even aware of its existance.
So we have three RFCs for this sort of feature:
RFC 1891 (most widely implemented, if at all)
RFC 3461 (obsoleting 1891)
RFC 2852
> It is in fact "standards track", and it allows for an
> SMTP (or presumably a "submission") client to request DSNs tracing a
> message through all the hops it makes. It also specifies
> that a DSN be
> sent when a message requesting delivery notification is relayed to a
> server not supporting DELIVERBY,
After I pointed out to Wietse RFC 3461 sec 10.8 about "relayed DSN", I
noticed it didn't really specify "relay tracking", but rather "the next
hop doesn't support DSN, so I'll report relay success", which seemed
only partially useful. I would imagine if one is going to actually
*want* "relay tracking" (such as a highly regulated institution), one
would want the whole set of relaying hops reported.
> DELIVERBY is quite a bit more sophisticated than RFC 3461 DSN
> w.r.t. requesting notifications of relaying and delivery and it gives
> the client control over the retry duration for all participating MTAs.
>
> I had forgotten that I had a note in my Smail ToDo file suggesting the
> implementation of DELIVERBY. :-)
Any other MTAs implement it? Third-party patch or otherwise? Do you have
any Smail code to modify for a Postfix patch? I don't think it's high on
Wietse's priority list right now.
> (Either DELIVERBY or DSN's NOTIFY are the only ways I would ever
> implement any kind of annoying "mail delayed" DSN -- i.e. if
> the client
> explicitly asked for such a notice.)
I would prefer an RFC implementation over a
"tail-the-logs-with-a-shell-script" hack any day.
|
|
|