Re: SRS sendmail integration

Stuart D. Gathman wrote:

> On Tue, 23 Mar 2004, Mark wrote:
>
>> The last line of EnvFromSMTP is:
>>
>> R$+   $: $>MasqEnv $1   do masquerading
>>
>> There are two good reasons to place SRS encoding at the end of
>> EnvFromSMTP. For one, since SRS encoding may alter the domain name
>> (!), doing it earlier might break masquerading in those cases. For
>> two, it simply makes sense to only make_srs after everything else
>> with the address is already done.
>>
>>> Similary, the SRS line for ruleset ParseLocal comes *after*, whereas
>>> Mark has me add it before.
>>
>> Conversely, before we have sendmail do any sort of checks on the
>> recipient, we do well to first revert the address back to a regular
>> recipient. My ParseLocal, for instance, normally starts with code
>> that does REDIRECT for users who have moved. It is, of course,
>> important that sendmail enters the standard part of ParseLocal as it
>> normally would, with a regular recipient.
>
> So how do we fix the m4 HACK?  I tried moving the HACK(`pysrs`) to
> after the mailers, but it didn't help.  It is still backward!  The
> problem seems to be that the HACK gets included in the middle,
> with ParseLocal coming before, and EnvFromSMTP coming after.
> So how do you get stuff included near the beginning? Near the end?

Good question. ;) Seriously, though, as I suspected, m4 does not provide
such fine-grained control. I asked, to be sure, and got word from Claus
Assman today, saying this is, indeed, not possible (if proto.m4 does does
provide the hook either; but editing proto.m4 leaves us exactly where
editing sendmail.cf leaves us). He said that when he himself was faced with
such a situation, that he just uses a patch file against the newly created
cf.

And it may just really come to that. So, we can provide m4 files; but then
the user may be required to move a line or two.

Regards,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx