Gerrit Pape <[EMAIL PROTECTED]> writes: > Hi, to be able to automatically send a reply to delivery > confirmation request messages, the program needs to reliably sort > out confirmation request messages from other delivery notifications > (bounces). It also needs to make sure that the confirmation request > message is not forged.
Yup. There are a few protocols for doing this in the works, and I've held off on implementing anything until I see how they flesh out. Those I'm aware of are: * The Challenge / Response Interworking (CRI) Framework http://www.ietf.org/internet-drafts/draft-irtf-asrg-cri-00.txt * The Receptionist protocol http://www.whitelist.com/protocol.html One of these might very well become the standard for C/R systems. > To make this possible, I suggest that confirmation request messages > are created with a special Message-ID. The Message-ID of the > request message is created from the Message-ID of the message that > causes the confirmation request, by prepending ``confirm-'', and > appending the local host part[0]. TMDA's confirmation request messages already include the requesting Message-ID in an 'In-Reply-To' header, but I suppose this isn't enough to distinguish it from other auto-responders, correct? You'd need the 'confirm-' string in there as well? > The latest qconfirm version does this, and it would be nice if tmda > and ask could do this also. Presuming that confirmation request > messages are sent to the envelope sender (should be self-evident), > qconfirm then would be able to auto-confirm delivery of messages to > tmda and ask users. The problem here is at least twofold as I see it: 1) Making this an optional feature wouldn't help, as there isn't any incentive for the TMDA user to turn it on. It would have to be enabled by default in order to be useful. 2) I don't want to implement something that only works between TMDA, qconfirm, and ASK. I'd like a method that is compatible with every C/R system out there (see above proposed standards). So, I'd hate to implement this, and then have to revoke it later in favor of something else. And yes, the Message-ID is involved in other proposals, so there is the possibility for an incompatibility. What are your thoughts on these issues? Do you have plans to push your proposal as something all C/R systems should adopt? _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
