On Sun, 7 Dec 2003 11:57:31 +0000 Gerrit Pape <[EMAIL PROTECTED]> wrote: > On Fri, Dec 05, 2003 at 08:42:21PM -0500, J C Lawrence wrote:
>> At least one of the proposed consent token protocols uses Message IDs >> which: >> a) contain an embedded consent token. >> b) are valid and deliverable email addresses (via plus addressing) >> for the address to which the consent token applies (which is how it >> is recognisable as applicable to that address in subsequent >> transmissions). >> Prepending tokens on Message IDs, which is really overloading the >> Message ID data, would interfere with such uses. > Does this also apply to delivery notifications (bounces, confirmation > requests, delay notices, ...)? It is unspecified, but I rather doubt it would be. In almost all cases the MTA generating the DSN is not party to the consent relationship, has no knowledge of what form the consent actually takes, let alone the encoding, and thus can't either know or manipulate that data. Consent is inherently implemented at the MUA and LDA levels, not MTA, as only those items have a chance of knowing the relationships their user has arranged. > I know of this usage of the Message-ID, I'm using something near it to > detect follow-ups through In-Reply-To or References, and to validate > confirmation requests. Yup. > But for delivery notifications, there's no need to provide such a > special Message-ID, I think. Notifications are directly connected > with exactly one message, and sent to the envelope sender of this > message only. I consider them as a entirely different type of mail > messages. Quite. More simply they don't represent and aren't necessarily part of a previously established consensual relationship (they can be given enough upstream knowledge/system propagation, but don't have to be). > The notification only is important for the sender of the original > message, not for the recipient, and the sender needs to know what > message it corresponds to. So constructing the Message-ID for a > delivery notification from the Message-ID of the message causing the > notification seems reasonable to me, and integrates well with the > proposal you mention above, as this is exactly the information that is > needed. Please correct me if I'm wrong. Prepending a keyword is a > bonus to make processing notifications automatically more easy. The same logic, and arguably better, would have the Message ID of the reported message quoted in the delivery-status part of the DSN. This is allowed under RFC 3464 as extension fields (2.4). I am not aware of the logic under which Message IDs are not required to be quoted in the delivery-status part as per-message fields. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
