About editheader
Stephan Bosch <[email protected]>
| Newsgroups | gmane.ietf.mta-filters |
|---|---|
| Message-ID | <[email protected]> |
Hi, I've recently started implementing the editheader extension and based on the specification (RFC 5293) I have a few questions. (1) This is the first extension to introduce an action command with match arguments (match type and comparator), apart perhaps from the "denotify" command of the long-deprecated notify extension. Some match types such as ":matches" introduce the side-effect of setting match variables when the variables extension is active (RFC 5229; Section 3.2). So, my question is: can deleteheader action of the editheader extension affect match variables or is that supposed to be disabled much like the body test? Intuitively, I would think it is supposed to be disabled, i.e. I feel no action command should influence match variables. Also, it is not really possible to short-circuit the 'test' as required in RFC 5229 Section 3.2, because all matching headers must be deleted and thus matching continues. What do you think? (2) If I understand the specification correctly, users can use the editheader extension to (accidentally) create invalid IMAIL (now RFC 5322, was RFC 2822) messages. Some header fields defined in the IMAIL specification have a restricted number of occurrences and some have a specific well-defined structure. The editheader specification does not require, recommend, nor mention keeping the message a valid RFC2822 message. The only syntactic restriction I see is the requirement that the field value complies with the "unstructured" nonterminal syntax from IMAIL. It is allowed to silently refuse certain modifications (e.g. deleting Received headers), but I would have expected some recommendations in this respect. For example, is it wise to allow adding a second 'Subject:' header, or to allow setting the 'Date:' header to some syntactically incorrect nonsense? More complex examples would include the requirement for a 'Sender:' header when more than one 'From:' mailbox is specified. Syntax problems can be handled the same as deleting a restricted header (silently ignore), however, enforcing the uniqueness (and presence) of certain headers is a bit more complicated. Bluntly refusing addheader when the header already exists makes modifying such headers impossible, especially when deleting the header first would not be allowed (e.g. for 'Date:'; it is unique AND required). Implicitly deleting the previous occurrence of such headers during addheader would be an option, but is that a good idea? Or am I just exaggerating this problem? Regards, Stephan. _______________________________________________ sieve mailing list [email protected] https://www.ietf.org/mailman/listinfo/sieve