Tony Finch:
On Wed, 8 Sep 2004, Wietse Venema wrote:
Tony Finch:
I mean that it's effectively impossible to disable the multiple recipient
function selectively (i.e. only in the cases that are a problem for
Sender-ID).
That's a too general claim.
You're right, I need to go into more detail.
Sure, the simplest approach is to disable multi-recipient deliveries for
all messages that contain at least one alias-forwarded recipient. This
is not needed when the MTA stores sufficient additional information so
that the scheduler can make a more informed decision (such as the before
aliasing recipient address in addition to the final recipient).
The problem is that (in general) my systems don't have enough local
information to know that a message they are passing from the Internet to
somewhere inside the University is later going to pass back out (which is
when the change needs to be made). In many cases the message will pass
back out via a route which does not pass though my systems.
The Sender ID spec suggests that Sender ID information is added by
the MTA that does the aliasing/forwarding.
Isn't the whole problem that you are trying to move that function
from the aliasing/forwarding MTA to a gateway MTA?
Please forgive the ASCII art:
-> relay -> inside machine
internet alias/forward
<---------- some recipients
There is a problem when you try to move that function from the
aliasing/forwarding MTA to the inbound relay, because the inbound
relay does not have enough information. Either the inbound relay
would slap on the same generic Resent- information on all mail, or
it would have to de-optimize all inbound deliveries and give each
recipient their own Resent- information, on the odd chance that
some will be forwarded out.
Likewise, there is a problem when you try to move that function
from the aliasing/forwarding MTA to an outbound relay. Only the
aliasing/forwarding MTA has accurate information. The outbound
relay would have to slap the same Resent- information on all mail.
Wietse