bin/69423: sendmail access-map issue
Helge Oldach
sendmailaccess at oldach.net
Thu Jul 22 03:00:32 PDT 2004
>Number: 69423
>Category: bin
>Synopsis: sendmail access-map issue
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jul 22 10:00:32 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator: Helge Oldach
>Release: FreeBSD 4.10-STABLE i386
>Organization:
>Environment:
System: FreeBSD localhost 4.10-STABLE FreeBSD 4.10-STABLE #1920: Sun Jul 4 00:28:34 CEST 2004 toor at sep.oldach.net:/usr/obj/usr/src/sys/GENERIC i386
>Description:
I am running a mail relay host with no local users. I have set up an
access map similar to this example:
To:denver.com RELAY
To:detroit.com RELAY
To:paul at home.com RELAY
The idea is that I want to relay anything destined for denver.com and
detroit.com, but when it comes to home.com, only mail destined for
paul at home.com should be forwarded. Anything else - including all other
mail recipients @home.com - should be rejected.
I am using a configuration file created from a slightly modified
/etc/mail/freebsd.mc - but the problem can be reproduced with the stock
freebsd.mc. Everything else is a stock 4-STABLE of 4th July.
Things work fine for denver.com and detroit.com, but everything else
gets rejected - including mails to paul at home.com. The latter is the
issue. Why does that happen?
Here's a debug output for check_rcpt paul at home.com:
# (echo .D{client_addr}216.136.204.117; echo .D{client_name}www.freebsd.org; echo check_rcpt \<paul at home.com\>) | sendmail -bt -Cfreebsd.cf
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> > > check_rcpt input: < paul @ home . com >
Basic_check_rcpt input: < paul @ home . com >
Rcpt_ok input: < paul @ home . com >
ParseRecipient input: < paul @ home . com >
CanonAddr input: < paul @ home . com >
canonify input: < paul @ home . com >
Canonify2 input: paul < @ home . com >
Canonify2 returns: paul < @ home . com >
canonify returns: paul < @ home . com >
Parse0 input: paul < @ home . com >
Parse0 returns: paul < @ home . com >
CanonAddr returns: paul < @ home . com >
ParseRecipient returns: paul < @ home . com >
SearchList input: < + To > $| < F : paul @ home . com > < D : home . com > < >
F input: < paul @ home . com > < ? > < + To > < >
F returns: < RELAY > < >
SearchList returns: < RELAY >
RelayTLS input:
RelayTLS returns: NO
D input: < home . com > < ? > < + To > < paul < @ home . com > >
D input: < com > < ? > < + To > < paul < @ home . com > >
D returns: < ? > < paul < @ home . com > >
D returns: < ? > < paul < @ home . com > >
Rcpt_ok returns: paul < @ home . com >
Relay_ok input: < paul @ home . com >
A input: < 216 . 136 . 204 . 117 > < ? > < + Connect > < 216 . 136 . 204 . 117 >
A input: < 216 . 136 . 204 > < ? > < + Connect > < 216 . 136 . 204 . 117 >
A input: < 216 . 136 > < ? > < + Connect > < 216 . 136 . 204 . 117 >
A input: < 216 > < ? > < + Connect > < 216 . 136 . 204 . 117 >
A returns: < ? > < 216 . 136 . 204 . 117 >
A returns: < ? > < 216 . 136 . 204 . 117 >
A returns: < ? > < 216 . 136 . 204 . 117 >
A returns: < ? > < 216 . 136 . 204 . 117 >
D input: < www . freebsd . org > < ? > < + Connect > < www . freebsd . org >
D input: < freebsd . org > < ? > < + Connect > < www . freebsd . org >
D input: < org > < ? > < + Connect > < www . freebsd . org >
D returns: < ? > < www . freebsd . org >
D returns: < ? > < www . freebsd . org >
D returns: < ? > < www . freebsd . org >
Relay_ok returns: www . freebsd . org
Basic_check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied"
check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied"
> #
The interesting thing is that the call to the SearchList ruleset does
indeed return "< RELAY >". So the access map is clearly correct. But
then there are additional calls to the D and A rulesets that apparently
eradicate the "RELAY" lookup. This happens within Rcpt_ok:
SRcpt_ok
R$* $: $>ParseRecipient $1 strip relayable hosts
# blacklist local users or any host from receiving mail
R$* $: <?> $1
R<?> $+ < @ $=w > $: <> <$1 < @ $2 >> $| <F:$1@$2> <U:$1@> <D:$2>
R<?> $+ < @ $* > $: <> <$1 < @ $2 >> $| <F:$1@$2> <D:$2>
R<?> $+ $: <> <$1> $| <U:$1@>
R<> <$*> $| <$+> $: <@> <$1> $| $>SearchList <+ To> $| <$2> <>
R<@> <$*> $| <$*> $: <$2> <$1> reverse result
R<?> <$*> $: @ $1 mark address as no match
R<$={Accept}> <$*> $: @ $2 mark address as no match
Debugging with sendmail -d21.4 yields:
[...]
ParseRecipient returns: paul < @ home . com >
rewritten as: paul < @ home . com >
rewritten as: < ? > paul < @ home . com >
rewritten as: < > < paul < @ home . com > > $| < F : paul @ home . com > < D : home . com >
SearchList input: < + To > $| < F : paul @ home . com > < D : home . com > < >
F input: < paul @ home . com > < ? > < + To > < >
rewritten as: < RELAY > < paul @ home . com > < ? > < + To > < >
rewritten as: < RELAY > < >
F returns: < RELAY > < >
rewritten as: < + To > $| < D : home . com > < > $| < RELAY > < >
rewritten as: < RELAY >
SearchList returns: < RELAY >
rewritten as: < @ > < paul < @ home . com > > $| < RELAY >
rewritten as: < RELAY > < paul < @ home . com > >
rewritten as: @ paul < @ home . com >
So we get a RELAY, but that is ignored by the rule with the $={Accept}
LHS above. Why does this happen?
There are similar rules in Basic_check_relay and Basic_check_mail, and
these two don't throw away the SearchList result but terminate the
rulesets. Why does Rcpt_ok behave differently?
Note the comment on the rule "mark as no match" - but we *do* have a
match. So why should we mark it as a no-match?
The rules immediately following this one just terminate the ruleset if
there is something in error. I believe that also the following checks
(on TLS, and on local users, both of which can be handled by different
mechanisms in access_db) in the ruleset are irrelevant to this case, so
it would be safe to just have
R<$={Accept}> <$*> $@ RELAY or just
$<RELAY> $* $@ RELAY
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list