On Sun, Feb 09, 2003 at 03:13:32PM -0800, Randall Gellens wrote: > At 11:29 AM +0100 2/9/03, Cliff Sarginson wrote: > > > > DSNs are requested at the SMTP (transport) level, and can result in > >> positive acknowledgment of a message's arrival at the last server > >> (the user's spool). It must be supported by the originating > >> submission program, and all servers in between. It does not indicate > >> if the message was ever downloaded by the user, but it can give a > >> reasonable indication that the message wasn't lost en route. > >> > > Mmm. As you are implying this does expect co-operation all the way down > > the line, plus the co-operation of the end-receiver. > > DSNs rely on cooperation from every server en route, including the > final one. To be more accurate, requesting non-default DSN behavior > requires this. By default, most servers generate failure DSNs which > include the full original message. The DSN extension mechanisms > allows the originator to request various non-default behavior, such > as success, relay, or delay DSNs, and can request that only the > headers of the original message be included. In addition, the > extension mechanism allows the originator to supply a unique > identifier which will be included in the DSN. These mechanisms are > great for mailing lists, for example, but could also be handy for > user agents to, for example, indicate to the author the current known > status of the delivery of a message to each recipient (success, > failure, delay, relay). Relay status indicates that the message was > passed to a server which does not support the DSN extensions. > > > I personally never > > allow DSN messages .. since I politically disapprove of them (but that > > is another story :) .. > > What about them do you disapprove of? > Traffic. > > They can generate a fair amount of more or less > > white-noise email, > > have you seen this? > Well, yes, at one place I worked it was de-facto.
> > and are unreliable at best. I don't think they can be > > relied upon as proof of anything very much anyway. > > I'm not sure DSNs are ever appropriate as "proof" of anything. Their > reliability is directly related to the proportion of servers that > support them. They can be useful. Certainly a failure DSN is very > useful. Oh I don't disagree with failure indications. But you get those anyway. But I think mail-systems of any use are built on the "Wells Fargo" principle .. "the mail must get through". An indication that it has not is good to know (maybe the mailman got shot by a bandit). An indication that it has is a bit overkill...just my view. But it is kind of a lot of baggage isn't it ? Maybe one day when email achieves a greater legal status than it has now, then non-repudiation of receipt will start to matter. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ]
