On Tue, 2007-04-03 at 22:07 -0700, Philip Guenther wrote:
On Wed, 4 Apr 2007, Kjetil Torgrim Homme wrote:
On Mon, 2007-04-02 at 14:58 -0600, Philip Guenther wrote:
...
(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.
It implies that
MAIL FROM:<guenther(_at_)sendmail(_dot_)com>
ENVID=foo(_at_)sendmail(_dot_)com
is not the same as
MAIL FROM:<guenther(_at_)sendmail(_dot_)com> 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.
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...
I agree the requirement for a verbatim "@" is not very pretty, and
probably not intended.
Tony, what do you say?
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.
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.
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?
(also a tiny typo, "case-insensitivie", and I think it should say "SMTP
RCPT TO command", not "SMTP RCPT command")
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.