ietf-mta-filters
[Top] [All Lists]

Re: comments on draft-freed-sieve-notary

2007-04-03 18:44:02

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.


<Prev in Thread] Current Thread [Next in Thread>