On Tue, Dec 02, 2003 at 07:41:56PM -0700, Jason R. Mastaler wrote: > 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?
Yes. I'm afraid that there may be MTAs out there that add a In-Reply-To header to bounces. The difference between confirmation requests and normal bounces must be definite. > You'd need the 'confirm-' string in there as well? Not necessarily, but I think it's a good idea to prepend a keyword here. The idea of creating a special Message-ID from the original Message-ID may be used for other types of delivery notifications also, and a different keyword could be used then. > > The latest qconfirm version does this, and it would be nice if tmda > > and ask could do this also. Presuming that confirmation request > 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. Yes. > 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. I don't think that there's a possibility for an incompatibility, that's why I now implemented the Message-ID trick. The ``Receptionist protocol'' you mention above uses the Message-ID as identifier, but doesn't require the Message-ID to be special. Current standards only require the Message-ID to be a unique identifier for this particular mail message, there's no restriction on how it's created. Creating the Message-ID for confirmation requests as I suggest doesn't break this, so it doesn't interfere with the proposed standards. > What are your thoughts on these issues? I think it'll take a long time until one of the proposed standards is accepted, and since the special usage of the Message-ID does nothing which could cause trouble for such proposed standards, it can be deployed right now. > Do you have plans to push your proposal as something all C/R systems > should adopt? I would like to see it adopted, but I'm not the man doing the pushing. I could write up a technical document on how it works, but my english skills are not good enough to push it, and convince other people. It would consume a lot of my time. Regards, Gerrit. -- Open projects at http://smarden.org/pape/. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
