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.
Roy Badami points out that I could add a Resent-From: header whenever a
message leaves my jurisdiction, whether that is further into the
University or out to the Internet. This depends on the servers in
departments and colleges to do the right thing, if we want the University
as a whole to be compliant. It also restricts the proportion of email that
can have multiple recipients.
This is all a great deal of effort and complexity. It's much simpler to
gain compliance by just sticking Resent-From:
mailer-daemon(_at_)ppsw(_dot_)cam(_dot_)ac(_dot_)uk
on every message (ppsw is the name of our relay for historical reasons);
this is not in the spirit of Sender-ID but it does the job without
de-optimising everything.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SOUTH FITZROY: CYCLONIC 3 OR 4. THUNDERY SHOWERS. MODERATE OR GOOD.