Dan_Mitton@??? wrote:
>>> Yes, that is exactly the problem. I might have an answer...
>>>
>>> forwarding_router:
>>> driver = redirect
>>> srs = forward
>>> data = $local_part@$domain
>>> srs_condition = \
>>> ${if and \
>>> { \
>>> {!eq{$sender_address}{}} \
>>> {match_ip{$sender_host_address}{+relay_from_hosts}} \
>>> {!match_domain{$sender_address_domain}{+relay_to_domains}} \
>>> } \
>>> }
>>>
>>> What I think I'm trying to say with the above code is:
>>>
>>> IF sender in not <> AND
>>> sender is someone I'd normally relay for AND
>>> sender's domain is a domain I don't relay for
>> Do these seem to be in conflict?
>>
>> i.e. - if the sender's domain is not one you relay fpr, how do you know
> the
>> sender is (one you relay for?) - or 'recognize' said sender.
>>
>
> Isn't the $sender_host_address the IP address of the sending server? I
> should be able to know that this came from my internal network (the
> servers I relay for).
Of course. But then is that not 'someone you DO' (or would) normally relay for?
Or do you mean you do not normally relay between/among your own domaisn, but are
willing to do so?
IOW a terminology conflict, not a technical one.
It only matters w/r the 'logic' you have illustrated. I think ee know what you
want to happen.
> If I'm missing something here, please let me know.
>
>>> THEN I'm not really acting as a relay, I'm acting more as a forwarder,
> so
>>> SRS the thing.
>>>
>>> Does that make any sense?
>> *snip*
>>
>>
>> Question;
>>
>> - Will the $local_part and/or $domain necessarily even have been
> preserved?
>> (presuming the notes server has instigated the forwarding...or used an
> alias)
>
> What is happening is 2 divisions of the same company (in this case, the
> government) div_a.company.com & div_b.company.com each with their own
> independent mail systems. Bill Jones transfers from div_a to div_b and is
> now named William Jones, but they want mail addressed to his old
> Bill.Jones@div_a.company.com address to get forwarded to
> William.Jones@div_b.company.com. The edge Exim server doesn't know
> anything about anyone. Exim just passes the Bill.Jones@div_a.company.com
> mail along to Notes. Notes decides that Bill's mail should be forwarded
> to William.Jones@div_b.company.com and hands a new message (from Exim's
> point of view) back to Exim. Because the original "MAIL FROM:" has been
> preserved, if the original sender has SPF records defined, when div_b gets
> it message, it will flag it as not having come from the original sender
> (because I forwarded it). If div_a can SRS the message before it gets
> forwarded, that (should, I hope) make div_b's SPF happy. So, I'm hoping
> that the Exim code would work something like - the message came form a
> server I relay (my Notes server) and the original senders domain (which
> might be anything) is not a domain I relay for, so SRS it. If the
> original sender IS a domain I relay for, I don't need to SRS, because I am
> the original sender. Sorry for the long story.
>
It suggests an Occam-ish solution:
Set your servers to recognize and trust each other by IP and NOT require SRS of
each other. Exemptions, IOW.
>> Or do you need some way to build a list/DB of 'who gets..(SRS applied)'.
>> And if so, might not that solve the problem 'up front'?
>>
>> i.e. - is there perhaps some way to scan for (the equivalent of) active
> .forward
>> files and/or aliases- then pre-load them into a list/Db for Exim - prior
> to
>> encountering traffic?
>>
>
> Yes, If I can't generalize a solution, this might be the way to go. But
> then I will have extract jobs and parsing and load jobs. I'd like to
> avoid that if possible.
>
>> IF you can query the Notes server - or whatever DB drives it - at all...
>
> Exim on one side of a firewall, Notes on the other, no access (other then
> SMTP) allowed.
>
>> IF NOT - your Exim may remain at least partially 'blind' to external
> events -
>> regardless of logical tests.
>>
>
> What sort of external events?
>
Changes in the user lists of the Notes servers.
>> Wonder if the Notes server could do the necessary?
>>
>
> It likely could, but this seems an easier place (not for technical
> reasons) to implement.
>
I'd go for a 'trust' model, and just not use SRS internally.
Bill
