On Mon, 2007-04-02 at 14:58 -0600, Philip Guenther wrote:
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,
+1
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.)
why do you think that is (mildly) broken? okay, it says "the syntax of
ENVID from RFC 3461 is extended [...]" when it's really *restricting*
it.
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?
it should be a different capability, MTRK is non-trivial to deploy in
clustered mail systems, DSN is much simpler. could be in the same
document, though.
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.)
yes.
This extension provides a means to test the notary values on incoming
messages, but not set them on messages sent via 'redirect'.
I guess you mean the NOTIFY parameter here, I don't think we want to
allow users to play with any of the others. that could probably be
useful (in particular NOTIFY=NEVER). I don't think it needs to be in a
separate capability.
another comment on the draft:
orcpt Match the original recipient, or ORCPT, value in decoded form
associated with the TO address used in the SMTP RCPT command that
resulted in this message getting delivered to this user. The
syntax and semantics of the ORCPT parameter are defined in RFC
3461 [RFC3461] section 4.2.
is the addr-type ("rfc822;") part of the value supposed to be stripped
off? perhaps we should extend ADDRESS-PART to make this explicit? or
we could say that :localpart and :domain strips off addr-type, but when
neither is specified, the complete value is used.
(also a tiny typo, "case-insensitivie", and I think it should say "SMTP
RCPT TO command", not "SMTP RCPT command")
--
Kjetil T.