James M Galvin <[EMAIL PROTECTED]> writes:
> Now you've got me curious. Can you describe what is complex about it?
windlord:~/work/rfc> wc -l rfc1894.txt
2187 rfc1894.txt
2,000 lines is complex. :) It's also fairly difficult to read. I've
helped implement a bounce system, the one currently used by Stanford
University for all invalid @stanford.edu addresses in fact, which I
believe to be fully compliant with RFC 2187, and the RFC was a pain to
follow.
It also requires at least reference to RFC 1893 for the status codes,
which is another 800 lines or so.
It requires both full-blown MIME parsing and full-blown header parsing
(which is probably reasonable these days, but certainly has slowed its
adoption -- MIME parsing has only in the past year or two really become
something I would want to rely on).
It doesn't just handle bounces; it also handles delivery notifications.
While I appreciate the advantages of generalizing a protocol, delivery
notifications are, at least in my opinion, a solution looking for a
problem, and their addition to the DSN standard definitely made it much
more complicated than it would have needed to be without them.
It sets up *three* new IANA registries, which thankfully you can mostly
ignore because you rarely need to use anything other than one or two
values for those fields. But that means yet more canonical data sources
to refer to when you try to parse the things.
Basically, there is a whole bunch of additional cruft that it accumulates
due to its desire to be able to handle all sorts of delivery notifications
(not just bounces, which are the real problem that needed solving) through
all sorts of very bizarre gatewaying situations that are only rarely
encountered in the wild. While I am sure that some of this would come in
handy if you ran one of those weird gateways, I'm inclined to think that a
protocol that would simplify a bit better for the 99% case would be
superior.
> The only real issue I have with it is that I can not find everything I
> need in one place. There are a few companion documents and I find it
> clumsy to track down details when I need them.
Yup, that's a big one.
> And then there is Sendmail....
sendmail actually isn't the MTA I would complain about in this space. If
you really want a standardized bounce format, the MTA that you're never
going to be able to get to join the fold is likely qmail, because Dan
Bernstein took one look at DSN and said "no way in hell."
Frankly, I'm sympathetic. I think it's an ugly protocol, and qmail's
bounce format at least has the significant advantages of simplicity and
clarity. I guess one of the points where I differ with Dan is that I'm
willing to implement an inferior protocol if it helps things work
together; software exists to hide complexity, and now that I've written a
DSN bounce generator, I can always just reuse that one and not worry about
how annoying the syntax is.
But in an ideal world....
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
