From hmo@sep.oldach.net  Thu Jul 22 09:50:53 2004
Return-Path: <hmo@sep.oldach.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 665C816A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 22 Jul 2004 09:50:53 +0000 (GMT)
Received: from sep.oldach.net (p5081C50A.dip0.t-ipconnect.de [80.129.197.10])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D6FE043D1F
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 22 Jul 2004 09:50:51 +0000 (GMT)
	(envelope-from hmo@sep.oldach.net)
Received: from sep.oldach.net (localhost [127.0.0.1])
	by sep.oldach.net (8.12.11/8.12.11/hmo03mar03) with ESMTP id i6M9oeBB032190
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO);
	Thu, 22 Jul 2004 11:50:40 +0200 (CEST)
	(envelope-from hmo@sep.oldach.net)
Received: (from hmo@localhost)
	by sep.oldach.net (8.12.11/8.12.11/Submit) id i6M9oY5x032181;
	Thu, 22 Jul 2004 11:50:34 +0200 (CEST)
	(envelope-from hmo)
Message-Id: <200407220950.i6M9oY5x032181@sep.oldach.net>
Date: Thu, 22 Jul 2004 11:50:34 +0200 (CEST)
From: Helge Oldach <sendmailaccess@oldach.net>
Reply-To: Helge Oldach <sendmailaccess@oldach.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc: sendmailaccess@oldach.net
Subject: sendmail access-map issue
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         69423
>Category:       bin
>Synopsis:       sendmail access-map issue
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gshapiro
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jul 22 10:00:32 GMT 2004
>Closed-Date:    Fri Dec 10 05:40:02 GMT 2004
>Last-Modified:  Fri Dec 10 05:40:02 GMT 2004
>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@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@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@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@home.com. The latter is the
issue. Why does that happen?

Here's a debug output for check_rcpt paul@home.com:

# (echo .D{client_addr}216.136.204.117; echo .D{client_name}www.freebsd.org; echo check_rcpt \<paul@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:
Responsible-Changed-From-To: freebsd-bugs->gshapiro 
Responsible-Changed-By: gshapiro 
Responsible-Changed-When: Sun Aug 15 00:18:16 GMT 2004 
Responsible-Changed-Why:  
Take responibility as sendmail maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=69423 
State-Changed-From-To: open->analyzed 
State-Changed-By: gshapiro 
State-Changed-When: Sun Aug 15 00:21:17 GMT 2004 
State-Changed-Why:  
This is actually the correct behavior.  FEATURE(`blacklist_recipients') 
is for blacklisting recipients just as the name implies, not whitelisting. 
The docs in cf/README state: 

blacklist_recipients  
Turns on the ability to block incoming mail for certain  
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
recipient usernames, hostnames, or addresses.  For  

The RELAY map value is documented in cf/README as: 

RELAY           Accept mail addressed to the indicated domain or  
^^^^^^ 
received from the indicated domain for relaying  
through your SMTP server.  RELAY also serves as  
an implicit OK for the other checks.  
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

Note the underlined portions. 

I will however add something to cf/README to make it absolutely clear 
that it can't be user for per-user relaying. 

I've also been working on some rules to do per-user relaying that I plan 
on publishing on sendmail.org when I am done. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=69423 
State-Changed-From-To: analyzed->closed 
State-Changed-By: gshapiro 
State-Changed-When: Fri Dec 10 05:39:04 GMT 2004 
State-Changed-Why:  
Functionality works as documented.  A future version will probably 
provide the functionality you are looking for. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=69423 
>Unformatted:
