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?
Exactly what I was thinking.
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).
And more to the point, the fact that a given recipient address hasn't actually
appeared in an SMTP dialogue in a RCPT TO field is 100% irrelevant. The message
envelope and its associated list of recipients is an abstraction that manifests
in a variety of ways, including but not limited to SMTP commands.
Another way to look at it is that when we talk about RCPT TO addresses we're
referring to the addresses in the envelope recipient list, not to those
addresses in the specific case where they happen to appear in SMTP. The
terminology choie is unfortunate, but after over 20 years changing it is simply
not realistic.
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"?
FWIW it's defined, more or less, as part of the NOTARY specifications.
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.)
There are really two issues here that overlap to some extent. One is the issue
that arises when a recipient address gets turned into something that isn't
globally meaningful or usable. properly. The other is what address to expose to
sieve for the purposes of performing envelope recipient tests.
THe overlap is only partial since there can be multiple global addresses
involved in addition to local addresses, so the choice of address to
expose isn't simply local/global.
Quite a few systems, ours included, use oddball local address forms at the
point of final delivery. I personally don't like this much, but in our case the
design was a fait accompli long before I was even involved. Even so, when this
is done the goal needs to be to minimize exposure of these local address forms,
for one simple reason: They don't work when someone enters then into their
email client.
As far as selecting the right address to use in envelope tests goes, I like to
apply the least astonishment principle: Use the address the user expects.
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.
Or even if there was no protocol involved at all.
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?
I tend to use the term "envelope recipient" or "final envelope recipient" or
something similar if I'm trying to avoid tying things to SMTP specifically. But
the reality is that the term "RCPT TO" is now used all the time for this even
when SMTP isn't necessarily part of the picture.
Ned