Subject: comments on draft-freed-sieve-notary

From: Philip Guenther <[email-masked]>
Date: Mon, 2 Apr 2007 14:58:35 -0600

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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 04 Apr 2007 03:29:42 +0200

On Mon, 2007-04-02 at 14:58 -0600, Philip Guenther wrote:
> have been more obvious to me,

+1

> 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.

> 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.

> its lower maturity level and deployment compared to DSN.)

yes.

> 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.

---

From: Philip Guenther <[email-masked]>
Date: Tue, 3 Apr 2007 22:07:03 -0700

> On Mon, 2007-04-02 at 14:58 -0600, Philip Guenther wrote:
...
> ENVID from RFC 3461 is extended [...]" when it's really *restricting*

It implies that
  	MAIL FROM:<[email-masked]> ENVID=[email-masked]
is not the same as
  	MAIL FROM:<[email-masked]> ENVID=foo+40sendmail.com

changing xtext from purely an encoding to at least partially an escaping 
mechanism.  You have to save the raw envid and not the decoded form. 
Does message tracking still work if a relaying MTA changes which 
characters in the envid are xtext encoded?  Certainly not if there's more 
than one '@' in the fully decoded form...

> useful (in particular NOTIFY=NEVER).  I don't think it needs to be in a

RET, and maybe ENVID, could also be useful.  The redirected message may 
have an ORCPT pointing at the redirecting account automatically added if 
it didn't have one before (per RFC 3461, 5.2.1(d)) *and* the envelope 
sender is not changed by the implementation's 'redirect' command.

> neither is specified, the complete value is used.

Ooog, this get ugly when the type _isn't_ rfc822.  Hmmm...

> RCPT TO command", not "SMTP RCPT command")

Disagree.  It should say "ESMTP RCPT command" to match RFC 3461.

Philip Guenther

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 04 Apr 2007 09:45:51 +0200

>   	MAIL FROM:<[email-masked]> ENVID=foo+40sendmail.com

I don't think that's true for the specific example -- 3885 says it only
modifies the ENVID parameter syntax when a MTRK parameter is present.

if I understand correctly, a message can't be "upgraded" to use MTRK,
only the original sender can set a MTRK tracking identity.  when a
message passes from MTRK+DSN to DSN only, MTRK is removed and ENVID is
kept intact, and DSN has loose interpretation of ENVID.

while the message is in the MTRK domain, the ENVID parameter must
contain at least one verbatim "@".  fqhn can contain neither verbatim
nor encoded "@", so there is no ambiguity.

> than one '@' in the fully decoded form...

I agree the requirement for a verbatim "@" is not very pretty, and
probably not intended.

Tony, what do you say?

> sender is not changed by the implementation's 'redirect' command.

I'm skeptical to allowing access to ENVID, since Sieve has no facility
for generating guaranteed unique tokens.  at most we should allow the
user to specify a cookie to be embedded in the system's generated ENVID.

good point about ORCPT, but you're not advocating that the user should
be allowed to influence it, are you?  in my opinion, the interaction
between "redirect" and ORCPT is not relevant for this document since it
is relevant for all mail systems which implement DSN.  in other words,
it should be in the base spec -- something for 3028ter?

> Disagree.  It should say "ESMTP RCPT command" to match RFC 3461.

okay, in that case "SMTP MAIL FROM" should be changed to "ESMTP MAIL",
too.

-- 
Kjetil T.