Magnus Holmgren wrote:
> On Thursday 25 January 2007 10:39, Philip Hazel wrote:
>> On Wed, 24 Jan 2007, Magnus Holmgren wrote:
>>>> I believe the problem is that the option is being expanded before an
>>>> actual connection is being established.
>>> Why don't we move that expansion to after the connection has been
>>> established? I can't see any problem with that, except that the
>>> expansion might fail and it doesn't look so good if Exim panics and
>>> drops the connection.
>> That seems plausible; Exim needn't drop the connection - it could just
>> send QUIT instead of {EH/HE}LO. As part of this, we would have to invent
>> two new variables for the outgoing interface. I propose
>> $sending_ip_address and $sending_port, by analogy with the (new) names
>> $received_ip_address and $received_port.
>
> Quoting the Changelog:
>
> | PH/43 Renamed the variables $interface_address and $interface_port as
> | $received_ip_address and $received_port, to make it clear that these
> | values apply to message reception, and not to the outgoing interface
> | when a message is delivered. (The old names remain recognized, of
> | course.)
>
> If the variables were renamed only because they don't apply to the outgoing
> interface, and we make it so they can apply to the outgoing interface as
> well, then they would not have to be renamed, would they?
>
>
Perhaps not, but what I believe we need is BOTH, AND the ability to (optionally)
store and recover the 'incoming' then force the same or a specified / related,
selection for outgoing (or not).
Separating the naming is a first step.
As the old terms are presently backward-compatible, I am looking for a similar
change to establish $sending_ip_address and $sending_port (or some similar
naming convention) to complete that severance.
The *other* step has to do with what needs to be done if/as/when Exim is
delivering more than one message to a given remote destination AND they have not
necessarily arrived on the same incoming IP/port set.
In the near term, that is already controllable, if by less than optimal means.
Bill Hacker
