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
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...
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.
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.
Ooog, this get ugly when the type _isn't_ rfc822. Hmmm...
(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.
Philip Guenther