Alessandro Vesely writes:
I don't recall this subject having been discussed on this list. Anyway, the expired draft is apparently coming back.
I don't recall seeing this either.Briefly skimming the latest document, I see one possible reason it expired without much interest: nobody could really tell what it's supposed to do. Although its overall purpose is somewhat clear, the meat and the bones of it is very muddy. Not a single example that I can find, and the description is full of vague references to other documents and concepts. After giving it a brief glance, I couldn't tell how it's supposed to work. It looks like you have to sit down, and slowly chew through this text, line by line, to figure out what it's trying to say. I'll go back and reread this when I have some more time.
There are not a lot of people writing mail servers out there. Although I can't speak for anyone else, I'd say it's a fair bet not many of them have the time to sit down and decipher this document.
See, that's the problem right there. If you want to have your proposal circulated far and wide, and widely adopted, you do not, I repeat, do not, want to require a secret decoder ring in order to descramble your specifications. People should be able to take 5 minutes of their time to briefly look through the document, see exactly what's going on. Make it crystal clear, right up front, how you go about to implement this, and leave the technical details and dry, formal specifications, to some other part of the document.
There's not a single example in this document. What a joke. Typical design-by-committee product coming out of IETF.
I think that, in general, this is a good idea, but it should not be necessary to present this in such a convoluted manner. Furthermore I do not see even a need to have any standard for this. A given mail server can start generating time-expired bounce addresses that are derived in any manner. Nobody else needs to care about it. The mail server would then refuse to accept any bounces to non-conforming bounce addresses, and that's the end of it.
The only problem here, and I suspect that whatever this document proposes also has the same flaw, is that you'll force your customer to use your mail server, so that it can munge the return address accordingly. If your customer uses someone else's mail server and uses your domain's return addresses, the other mail server won't, obviously, be able to munge the return address properly, and your server will reject any bounces.
pgpDKWxIEn4GD.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
