On Wed, Dec 04, 2002 at 09:21:37AM +0000, Nigel Metheringham wrote: > > RFC1894 > > is for MTAs. The UA generates only the request. The MTA generates the > > response. Dr. QMail dismisses rfc1894 as entirely obsolete. DJBernstien > > has his own method but, AFAIK, he didn't write an RFC, so chances of a > > standard emerging from 'The QMail Way' are somehwat difficult to > > prognosticate. > > Frankly no one is much interested in RFC1894 - I think sendmail does at > least partially implement it (which is a shame - it legitimises it), but > the other mainstream mailers give it a wide berth. Here's a quote from > the exim list:- > http://www.exim.org/mailman/htdig/exim-users/Week-of-Mon-19990927/014475.html > > Nigel.
It is interesting that so many problems arise in trying to implement the old "return receipt to:" in a more secure, respectful, coherent manner. I thought there was something in the DSN RFC that carried the implicit (if not explicit) requirement that exactly 1 MTA is responsible for deliveries to any 1 email address. And that a notification of delivery was only an acknowledgement from the responsible MTA that the message was delivered. In this case '.forward' is irrelevant. Presumably the responsible MTA would indicate in the header that the DSN response had already been sent. Any further, down stream MTA should ignore the already satisfied request. I think both RFCs stem from X.400, where all the parameters are excruciatingly well obscured, er, a... well defined;^) Either way 2298 is pretty clean. Cheers, JPK
msg11719/pgp00000.pgp
Description: PGP signature
