I found the extension name to be relatively obscure, having completely
forgotten that the DSN work came from the notary WG. "smtp-dsn" would
have been more obvious to me, but perhaps that implies a restriction to
SMTP that doesn't exist. (Is there a reasonable X.400 mapping for these
envelope values?)
It should be stated that any ADDRESS-PART argument is ignored when
matching against the 'notify' or 'ret' envelope parts. I suggest that it
_not_ be ignored for 'envid' due to RFC 3885's tightening of the envid
syntax when message tracking is used.
(Hurm. RFC 3885's seems at least mildly broken, as it apparently implies
that an "@" is not the same as its xtext encoded version.)
Speaking of RFC 3885, would it be reasonable to have this "notary"
extension also define a "mtrk" envelope-part given how MTRK is tied to the
notary parameters? Or should that be a different capability?
mtrk Match the message tracking, or MTRK, value given in the
SMTP MAIL FROM command. The syntax and semantics of the MTRK
parameter are defined in RFC 3885 [RFC3885] section 3.1.
(It may make sense to do MTRK in a separate extension simply because of
its lower maturity level and deployment compared to DSN.)
An example of how to test whether 'notify' contained a specific set of
values would help clarify the behavior. Perhaps something like:
# Check whether only FAILURE notifications were requested
if allof ( envelope "notify" "FAILURE",
envelope :comparator "i;ascii-numeric" :count "eq"
"notify" "1"
)
{
# do whatever
}
This extension provides a means to test the notary values on incoming
messages, but not set them on messages sent via 'redirect'. Has anyone
played with extensions for setting SMTP parameters on outgoing messages in
sieve?
Philip Guenther