On Wed, 2005-05-04 at 10:11 -0400, Mark E. Mallett wrote:
PS: my own implementation uses the final delivery address as the address
in the 'envelope "to"' sieve test, contrary to RFC3028 which says that
the SMTP RCPT TO address must be used. You all can tell me how wrong
this choice of implementation is, and I would simply have to agree that
it's a violation, but I just don't find the RCPT TO address to be of
anywhere near as much interest to the script as the actual resolved
individual delivery address; not to mention the fact that the RCPT TO
address can't nececessarily be guaranteed to be consistent as
implementations evolve.
_which_ SMTP RCPT TO?
in many environments, the expansion happens at one server and delivery
at another. it's simply impossible to pass information about the
"original" RCPT TO on to the next server when the alias is an actual
expansion (ie. more than one recipient address). 3028 even says as
much:
If one of the envelope-part strings is (case insensitive) "to", then
matching occurs against the TO address used in the SMTP RCPT command
that resulted in this message getting delivered to this user. Note
that only the most recent TO is available, and only the one relevant
to this user.
what's a "final delivery address"?
in our case with Cyrus as the server, the delivery address isn't
necessarily a routable e-mail address(!), as it's rewritten from
f(_dot_)m(_dot_)lastname+detail(_at_)domain to
username+detail(_at_)domain(_dot_) in other words,
our system is contrary to RFC 3028, too. (I should point out that Cyrus
can be used in a strictly compliant manner, but not at our site.)
IMO it is a reasonable interpretation to use the _latest_ ("final" if
you will) recipient address. never mind the fact that the latest RCPT
TO happened across LMTP rather than SMTP. I think the base spec should
be changed to reflect this more clearly. I would prefer wording which
allowed Cyrus to work like today, leaving alias knowledge to the MTA.
changing "SMTP" to "SMTP or LMTP" is sufficient for that, but it
probably won't do for Mark. suggestions?
--
Kjetil T.