Mailing List Archive

begin Tuesday 23 March 2004 20:25, Stuart D. Gathman quote:
> [root@spidey mail]# /usr/lib/sendmail -bt -Cspidey.cf
> WARNING: Ruleset ParseLocal=98 has multiple definitions
> WARNING: Ruleset EnvFromSMTP has multiple definitions
> ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
> Enter <ruleset> <address>
>
>
> I was amazed that the cf macros were smart enough to merge lines
> from multiple features for a subroutine. But I apparently didn't
> need to be. :-)
>
> Or is sendmail smart enough to do this, even though it complains with
> a warning? Or does it use the last definition?

It is sendmail that is smart enough to do the merging. If there are
several S lines with the same ruleset name, all rules are merged
within that same ruleset.

The warning also only occurs for sendmail -bt (testing mode), not for
actually running sendmail in queue or daemon mode. Probably, the
reasoning is that the multiple definitions might be accidental, and
that's why testmode warns about it. However, if you know that it is
intentional, you can safely ignore the warning.


http://www.busan.edu/~nic/networking/sendmail/ch29_01.htm#SML2-CH-29-SECT-1-5

Rule sets need not be declared in any particular order. Any order
that clarifies the intention of the configuration file as a whole
is acceptable. If a rule set appears more than once in a
configuration file, V8 sendmail will print a warning:

WARNING: Ruleset name redefined Prior to V8.8
WARNING: Ruleset name has multiple definitions V8.8

...
Note that the warning is given in all cases prior to V8.8, but
beginning with V8.8, it is issued only in -bt rule-testing mode or
if the -d37.1 debugging switch is set.

Alain

On Tue, 23 Mar 2004, Alain Knaff wrote:

> begin Tuesday 23 March 2004 18:29, Mark quote:
> > I really like the extra IsSrs macro; it saves resources not having to call
> > the srs2envtol script when we already know we are not dealing with an SRS
> > address. :) With your permission, I'd like to add this useful macro to my
> > "sendmail integration" page.
>
> No problem, go ahead
>
> > Moreover, I suggest a minor change:
> >
> > Kis_srs regex ^<?SRS[0-9]=.*
> >
> > To:
> >
> > Kis_srs regex ^<?SRS[01]=.*
>
> How future-proof is this? Do we risk having SRS2, SRS3, etc. one day?

One would hope not. We didn't originally expect to have 0 and 1, but we
put the digit in there just in case. Using [0-9] won't hurt.

People writing Perl applications should be using the exported $SRS0RE and
$SRS1RE from Mail::SRS. *poke* *poke*

Perhaps I should also provide a $SRSRE. Any takers?

This thread has now gone to srs-discuss.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

spf@anarres.org wrote:

>>> Moreover, I suggest a minor change:
>>>
>>> Kis_srs regex ^<?SRS[0-9]=.*
>>>
>>> To:
>>>
>>> Kis_srs regex ^<?SRS[01]=.*
>>
>> How future-proof is this? Do we risk having SRS2, SRS3, etc. one day?
>
> People writing Perl applications should be using the exported $SRS0RE
> and $SRS1RE from Mail::SRS. *poke* *poke*

Which reminds me. This regex should really be:

Kis_srs regex ^<?SRS[01][+=-].*

Cheers,

- Mark

System Administrator Asarian-host.org

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