Subject: TECH-OMISSION (-core): alias-forwarding and multiple recipients

From: Tony Finch <[email-masked]>
Date: Tue, 7 Sep 2004 11:06:46 +0100

It is not clear how alias-forwarders are supposed to handle messages with
multiple recipients. When handling such a message, Exim and some other
MTAs will determine the final alias destination(s) of all addresses in the
recipient list before delivery starts, so that only one copy of the
message needs to be sent to each destination host.

Say for example a message is sent to two addresses at an alumni forwarding
service: [email-masked], [email-masked]. If both of these
addresses happen to forward to the same place, say [email-masked] and
[email-masked], then the alumni.cam.ac.uk system will want to send one
copy of the message to the dotat.at system with multiple recipients. What
address should it use in the Resent-From: header? It can't use both
addresses, because then it would have to add a Resent-Sender: header and
we get back to the original question (and anyway the draft doesn't allow
for alias-forwarders to add a Resent-Sender: header).

Perhaps the forwarder should just use [email-masked]
as the Resent-From: address on all messages it handles?

The problem is more tricky of the forwarder is dealing with multiple
virtual domains. The central email relay of the University of Cambridge
(known as ppsw.cam.ac.uk) handles over 150 virtual mail domains. Which
domain should it use in the Resent-From: address when a message was
originally sent to addresses in two different domains which alias-forward
to the same domain? Since ppsw.cam.ac.uk is a valid mail domain used only
for operational purposes, perhaps it should just add Resent-From:
[email-masked] to all messages it handles?

Note that this would not do anything to protect the mail domains that are
actually used by our users!

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: EAST OR NORTHEAST 5 OR 6, OCCASIONALLY 7 IN NORTH. THUNDERY SHOWERS.
MODERATE OR GOOD.

---

From: Roy Badami <[email-masked]>
Date: Tue, 7 Sep 2004 23:41:54 +0100

>>>>> "Tony" == Tony Finch <[email-masked]> writes:

    Tony> It is not clear how alias-forwarders are supposed to handle
    Tony> messages with multiple recipients. When handling such a
    Tony> message, Exim and some other MTAs will determine the final
    Tony> alias destination(s) of all addresses in the recipient list
    Tony> before delivery starts, so that only one copy of the message
    Tony> needs to be sent to each destination host.

It seems to me that the best solution would be for the forwarder to
send a separate copy of the message for each recipient, so it can in
each case use the original destination address in the Resent-From
field.

	-roy

---

From: Tony Finch <[email-masked]>
Date: Tue, 7 Sep 2004 23:47:51 +0100

> each case use the original destination address in the Resent-From

This is both suboptimal and technically extremely difficult to do without
de-optimising all email handling, as opposed to just the cases that are a
problem for Sender-ID. If you consider also alias-forwarding via a
departmental server it's even worse.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
THE MULL OF GALLOWAY TO MULL OF KINTYRE INCLUDING THE FIRTH OF CLYDE AND THE
NORTH CHANNEL: EAST VEERING SOUTHEAST 3 OR 4, OCCASIONALLY 5 LATER. FAIR.
GOOD. SLIGHT.

---

From: Roy Badami <[email-masked]>
Date: Wed, 8 Sep 2004 00:08:40 +0100

>>>>> "Tony" == Tony Finch <[email-masked]> writes:

    Tony> This is both suboptimal

How common is it for a forwarder to receive a message with multiple
recipients all of which require forwarding to the same MX...?

    Tony>  and technically extremely difficult to do without
    Tony> de-optimising all email handling, as opposed to just the
    Tony> cases that are a problem for Sender-ID.

Do you mean that it's difficult to configure existing MTAs to behave
in this way, or that it would be difficult to introduce such
functionality into an MTA...?  I would find the latter surprizing...

I'm assuming that if Sender ID progresses to Proposed Standard, then
the major MTAs will grow native support for it...

    Tony> If you consider also alias-forwarding via a departmental
    Tony> server it's even worse.

If all departmental MTAs are upgraded to be Sender ID compliant, I
don't see the problem problem?  You only add Resent-From when you're
forwarding outside of your adminstrative domain.

During the transtion you may need to keep track of which departmental
servers are Sender ID compliant and which are not, of course...

	-roy

---

From: Daniel Senie <[email-masked]>
Date: Tue, 07 Sep 2004 19:56:03 -0400

>each case use the original destination address in the Resent-From

This is a significant change that would be quite problematic. The mechanism 
exists and is heavily used. My opinion is that a method to work with it is 
needed, as there's zero likelihood of depricating its use worldwide (let 
alone the efficiency reasons why deprication would be a terrible idea).

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2004 09:12:39 +0100

> recipients all of which require forwarding to the same MX...?

If we disabled the multiple recipient function our outgoing message load
would rise by 20%.

> functionality into an MTA...?

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).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
MULL OF KINTYRE TO ARDNAMURCHAN POINT: SOUTHEAST 3 OR LESS INCREASING 4 OR 5.
FAIR. GOOD. SLIGHT.

---

From: [email-masked] (Wietse Venema)
Date: Wed, 8 Sep 2004 07:58:46 -0400 (EDT)

> function selectively (i.e. only in the cases that are a problem for

That's a too general claim.  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).

	Wietse

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2004 14:02:20 +0100

On Wed, 8 Sep 2004, Wietse Venema wrote:
> 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

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: [email-masked]
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  <[email-masked]>  http://dotat.at/
SOUTH FITZROY: CYCLONIC 3 OR 4. THUNDERY SHOWERS. MODERATE OR GOOD.

---

From: [email-masked] (Wietse Venema)
Date: Wed, 8 Sep 2004 11:07:54 -0400 (EDT)

> 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