8.9.1 check_mail seems a little broken...
Ian Ward
the anti spam stuff seems a little borken. our system is receiving alot of
mail find but some people are having trouble sending (getting reject 501).
If I do a DNS lookup they seem ok to me.
for two people in particular, here is the maillog entry.....
Oct 18 04:36:33 firewall1 sendmail[1428]: EAA01428: ruleset=check_mail,
arg1=<cma...@globusandcosmos.com>, relay=titan.mciconnect.com [207.173.8
4.135], reject=501 <cma...@globusandcosmos.com>... Sender domain must exist
Oct 18 12:41:44 firewall1 sendmail[1599]: MAA01599: ruleset=check_mail,
arg1=<peter....@bellsouth.co.nz>, relay=firewall.bellsouth.co.nz [203.
97.94.120], reject=501 <peter....@bellsouth.co.nz>... Sender domain must
exist
If I do a DNS query on these domains they look fine to me. .....
MX records returned (using wspinger on win95)...
bellsouth.co.nz.
10, firewall.bellsouth.co.nz.
globusandcosmos.com.
10, mcicc1nt1.mciconnect.com.
All records.........
bellsouth.co.nz.
10, firewall.bellsouth.co.nz.
bellsouth.co.nz.
nameserver = ns1.clearview.co.nz.
bellsouth.co.nz.
nameserver = ns1.waikato.ac.nz.
globusandcosmos.com.
nameserver = NS1.XOR.COM.
globusandcosmos.com.
nameserver = NS2.XOR.COM.
globusandcosmos.com.
nameserver = NS3.XOR.COM.
Do these people have a problem or do I have a problem
(with setup that is.. hey I know I have problems ;)
Can I simply put an entry in the access database like...
bellsouth.co.nz OK
regards Ian.
Claus Assmann
>the anti spam stuff seems a little borken. our system is receiving alot of
It isn't... must be something else.
>mail find but some people are having trouble sending (getting reject 501).
>If I do a DNS lookup they seem ok to me.
Do you lookup these hostnames on the same machine where sendmail is
running?
>Oct 18 04:36:33 firewall1 sendmail[1428]: EAA01428: ruleset=check_mail,
>arg1=<cma...@globusandcosmos.com>, relay=titan.mciconnect.com [207.173.8
>4.135], reject=501 <cma...@globusandcosmos.com>... Sender domain must exist
Does it work for other domain names?
Esp. for those which have only MX records?
What's the output of
sendmail -bt
> /mx bellsouth.co.nz
> /mx globusandcosmos.com
> /map host globusandcosmos.com
something like this?
getmxrr(globusandcosmos.com) returns 1 value(s):
mcicc1nt1.mciconnect.com.
and:
map_lookup: host (globusandcosmos.com) returns globusandcosmos.com. (0)
What's your service switch configuration?
Which resolver library do you use for sendmail?
--
<URL: http://www.informatik.uni-kiel.de/%7Eca/ >
Please don't send me copies of usenet postings. Thanks!
Warning: the From: address is "spam protected". Make sure
you use "reply" if you want to send me e-mail.
Ian Ward
Sincere thanks for your time......
>Do you lookup these hostnames on the same machine where sendmail is
>running?
no I was using a lookup tool wspinger on a windoze pc.
>>Oct 18 04:36:33 firewall1 sendmail[1428]: EAA01428: ruleset=check_mail,
>>arg1=<cma...@globusandcosmos.com>, relay=titan.mciconnect.com [207.173.8
>>4.135], reject=501 <cma...@globusandcosmos.com>... Sender domain must
exist
>
>Does it work for other domain names?
>Esp. for those which have only MX records?
See later....
>What's the output of
>sendmail -bt
>> /mx bellsouth.co.nz
>> /mx globusandcosmos.com
>> /map host globusandcosmos.com
# /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /mx bellsouth.co.nz
getmxrr(bellsouth.co.nz) returns 1 value(s):
firewall.bellsouth.co.nz.
> /mx globusandcosmos.com
getmxrr(globusandcosmos.com) returns 1 value(s):
mcicc1nt1.mciconnect.com.
> /map host globusandcosmos.com
map_lookup: host (globusandcosmos.com) returns globusandcosmos.com. (0)
> /map host sydunix
map_lookup: host (sydunix) returns sydunix.globus.com.au. (0)
> /map host sydunix.globus.com.au
map_lookup: host (sydunix.globus.com.au) returns sydunix.globus.com.au. (0)
> /map host galprint
map_lookup: host (galprint) returns galprint.globus.com.au. (0)
>What's your service switch configuration?
no /etc/service.switch file
/etc/resolv.conf....
domain globus.com.au
nameserver 203.8.183.1
nameserver 192.189.54.33
>Which resolver library do you use for sendmail?
bind is 8.1.2 (a friend built sendmail for me)
On RedHat 5.1
The only strange tweak that I have done that you could say is not normal is,
# who gets all local email traffic ($R has precedence for unqualified names)
DHsydunix
# name resolver options
O ResolverOptions=HasWildCardMX
#O ResolverOptions=+AAONLY
The HasWildCardMX stopped the problem of the sysem not accepting mail when
DH was configured,
Oct 18 19:11:10 firewall1 sendmail[1759]: TAA01759: SYSERR(root): MX list
for sydunix points back to firewall1.globus.com.au
OK... my big problem is that the system will give me the reject 501 message
and refuse to relay anything from the SCO box (always). It will relay any
mail from the PC's (ie galprint in sendmail -bt above) just fine. I have
entries from outside with 501 rejects, and then immediately afterwards an
accept! like.....
Oct 19 10:10:29 firewall1 sendmail[2497]: KAA02497: ruleset=check_mail,
1=<and...@incognito.com.au>, relay=[210.15.225.200], reject=501
<and...@incognito.com.au>... Sender domain must exist
Oct 19 10:10:29 firewall1 sendmail[2497]: KAA02497:
from=<and...@incognito.com.au>, size=0, class=0, pri=0, nrcpts=0,
proto=ESMTP, relay=[210.15.225.200]
The error that is logged when the sco box tries to relay is....
Oct 20 14:48:45 firewall1 sendmail[3589]: OAA03589: ruleset=check_mail,
arg1=<mm...@globus.com.au>, relay=sydunix.globus.com.au [10.2.1.20],
reject=501 <mm...@globus.com.au>... Sender domain must exist
Could it be that the DNS does not answer quick enough?
If I change the /etc/hosts entry for sydunix.globus.com.au to just sydunix
the log entry changes so I can be sure it is finding the "relay=" info in
the /etc/hosts file.
I had a play with the sendmail -bt that you suggested and verified that my
entry in /etc/mail/mailertable of
sydunix.globus.com.au smtp:[sydunix]
speeds up the /map host command considerably
Is there a way to disable this part of check_mail untill I get a solution.
At the moment I have the SCO box connecting directly to the ISP's mail relay
(via masquerading)
Thanks again for your input.
Ian (bewildered) Ward
Claus Assmann
># /usr/lib/sendmail -bt
This is on firewall1 ?
>> /mx bellsouth.co.nz
>getmxrr(bellsouth.co.nz) returns 1 value(s):
> firewall.bellsouth.co.nz.
>The only strange tweak that I have done that you could say is not normal is,
># who gets all local email traffic ($R has precedence for unqualified names)
>DHsydunix
># name resolver options
>O ResolverOptions=HasWildCardMX
First: can you remove the wildcard MX record?
If you can't: can you remove the resolver option and use
DH[sydunix]
that should avoid MX lookups for the host.
>OK... my big problem is that the system will give me the reject 501 message
>and refuse to relay anything from the SCO box (always). It will relay any
>mail from the PC's (ie galprint in sendmail -bt above) just fine.
That's really wierd. But I don't really know what's causing this.
If the DNS has a problem, then the return value should be a temporary
fault and sendmail will log just a 451 warning. Was your sendmail built
against the include files of BIND 8.1.2?
>Is there a way to disable this part of check_mail untill I get a solution.
You can use this FEATURE:
accept_unresolvable_domains
Normally, MAIL FROM: commands in the SMTP session will be
refused if the host part of the argument to MAIL FROM: cannot
be located in the host name service (e.g., DNS). If you are
inside a firewall that has only a limited view of the
Internet host name space, this could cause problems. In this
case you probably want to use this feature to accept all
domains on input, even if they are unresolvable.
I would assume that there's something wrong with your DNS.
You write that you can reproduce the error always from one system,
while another one works, correct?
Do you have a chance to run the daemon with debug options (see
src/TRAC* for those which refer to DNS lookups)? You can maybe
even setup another sendmail daemon on a different port for
debugging.
Ian Ward
>"Ian Ward" writes:
>
>># /usr/lib/sendmail -bt
>
>This is on firewall1 ?
Yes it was.
>># name resolver options
>>O ResolverOptions=HasWildCardMX
>
>First: can you remove the wildcard MX record?
>If you can't: can you remove the resolver option and use
>DH[sydunix]
>that should avoid MX lookups for the host.
Yes. THANKS that is great advice. I did not realize I could use the ['s in
the .cf file as well <clunk doh!> this will simplify my setup <kiss is
good>. Previously removing the HasWildCardMX option has always meant the
return of the local configuration error regardless of any other
tweaks.......
Oct 18 19:11:10 firewall1 sendmail[1759]: TAA01759: SYSERR(root): MX list
for sydunix points back to firewall1.globus.com.au
>That's really wierd. But I don't really know what's causing this.
>If the DNS has a problem, then the return value should be a temporary
>fault and sendmail will log just a 451 warning. Was your sendmail built
>against the include files of BIND 8.1.2?
I will have to check with my coleague on this, he has been overseas this
last week. This is a possibility that I must follow up.
>>Is there a way to disable this part of check_mail untill I get a solution.
>accept_unresolvable_domains
OK. I will keep this as my last resort.
> Normally, MAIL FROM: commands in the SMTP session will be
> refused if the host part of the argument to MAIL FROM: cannot
> be located in the host name service (e.g., DNS). If you are
> inside a firewall that has only a limited view of the
> Internet host name space, this could cause problems. In this
> case you probably want to use this feature to accept all
> domains on input, even if they are unresolvable.
I think I have proven to myself that sendmail is performing the reverse
lookup ok, as changing the /etc/hosts entry from just a hostname to a FQDN
changes the relay= field in the log entry thus....
relay=sydunix.globus.com.au [10.2.1.20] or relay=sydunix [10.2.1.20],
>I would assume that there's something wrong with your DNS.
>You write that you can reproduce the error always from one system,
>while another one works, correct?
Yes, I will use the [entry] (my new weapon against the ISP's DNS setup) to
further debug. Although if I do a lookup myself for sydunix.globus.com.au I
get the identical DNS info returned (just MX stuff) than if I do a lookup on
"galprint.globus.com.au" which is the PC that is relaying fine. The DNS is
managed by the ISP, firewall1 is the only host with an "A" record.
Perhaps the problem is related to the formation of the headers from the SCO
box as my tests have proven that all other hosts(pc's actually) are relayed
fine. I captured a copy of the raw message whilst it was in the SCO box's
outgoing queue and examined the header. A question I forgot to ask last
night was related to EXACTLY which line is being parsed by sendmail. Here
is the mail message text as it appeared in the SCO smtp queue directory (I
edited the addresses a little).......
-------------------------------------------------------
Date: Tue, 20 Oct 1998 16:22:38 +1000 (EST)
From: Superuser <root-nospam-$%$%@globus.com.au>
X-Sender: root@sydunix
To: ian-nospam-$%$%@cyberpro.com.au
Subject: test
Message-ID: <Pine.SCO.3.96.981020162226.2618A-100000@sydunix>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: root-nospam-$%$%@globus.com.au
test
-------------------------------------------------------
althought the SCO box is configured to hide behind globus.com.au, not all
fields have a fqdn. You mentioned it is the From: field that check_mail
examines.. correct?
>Do you have a chance to run the daemon with debug options (see
>src/TRAC* for those which refer to DNS lookups)? You can maybe
>even setup another sendmail daemon on a different port for
>debugging.
thanks for your input, I will do some more debugging.
Ian Ward
All things are running MUCH better.
I removed the HasWildCardMX from resolver options and used the [brackets]
for the DH[sydunix] entry. Mail is now forwarded to the SCO box without
complaining of the MX loop.
Still got lots of 501 rejects. In your comments you asked wether the
rejects only happened for domains that only had MX records. You were right.
I have put -AAONLY in the resolver options and that has setlled everything
down. NO MORE REJECTS.. Yipee!!!
The only issue left is for me to reconfigure the SCO box to forward to the
firewall instead of directly out the masqueraded interface to the ISP's mail
relay.
I expect this to now work OK as the system would have been complaining about
the lack of class A name for the sydunix box (hopefully anyway... there is
generally no such thing as a coincidence in this game)
Thanks for all your help. Hopefully this will be put to bed tommorrow.
Sincerely, Ian Ward
@ozone.fmi.fi Kari E. Hurtta
"Ian Ward" <news...@cyberpro.com.au> writes:
> # name resolver options
> O ResolverOptions=HasWildCardMX
> #O ResolverOptions=+AAONLY
Well. It is known that check_mail does not work with HasWildCardMX
(or host -map does not work that way what check_mail wants, when
HasWildCardMX is set.)
/ Kari Hurtta
@ozone.fmi.fi Kari E. Hurtta
Clarify:
If HasWildcardMX is used, MX records are not used for canonify
hostnames. Because check_mail looks if hostname can be canonified,
that causes rejection for MAIL FROM:<aa...@bbbb.cc> where
bbbb.cc have only MX record (because bbbb.cc does not canonify).
RELEASE_NOTES:
| 8.7/8.7 95/09/16
<...>
| Add "HasWildcardMX" suboption to ResolverOptions; if set, MX
| records are not used when canonifying names, and when MX
| lookups are done for addressing they must be fully
| qualified. This is useful if you have a wildcard MX record,
| although it may cause other problems. In general, don't use
| wildcard MX records. Patch from Motonori Nakamura.
/ Kari Hurtta
Ian Ward
As you can see by my previous post, I thought everything was going smoothly.
Unfortunately, I was wrong.. <arghhh> The sendmail system was very happy,
but the SCO box "sydunix" started bouncing the mail. I did not notice the
return messages going out bouncing the mail.
alas, I am back to the only working config, resolver options=HasWildCardMX
and the SCO box relaying directly to the ISP.
I am convinced this is an error in the implementation of sendmail.
previously I said,
>>The only strange tweak that I have done that you could say is not normal
is,
>># who gets all local email traffic ($R has precedence for unqualified
names)
>>DHsydunix
>
>># name resolver options
>>O ResolverOptions=HasWildCardMX
Claus replied (and I agree this should work)
>First: can you remove the wildcard MX record?
>If you can't: can you remove the resolver option and use
>DH[sydunix]
>that should avoid MX lookups for the host.
removing the HasWildCardMX AND placing sydunix in square brackets DID fix
the MX loop problem.
It behaves correctly, forwarding all local mail to sydunix, resolving the
name using the /etc/hosts file.
*****But sendmail includes the [ ]'s in the hosts address*****
the returned mail is as follows:
Your message could not be delivered to
'mkoussas@"[sydunix]" (host: mailrelay.globus.com.au) (queue: badhosts)' for
the following
reason: ' <mkoussas@"[sydunix]">... Host[sydunix]not known--please specify
domain'
surely if sendmail is smart enough to realize the square brackets mean
ignore DNS and allow the local host to resolve the name, it should be smart
enough to strip off the [ ]'s ???????????
should sendmail also have a rewriting rule to fix the [ ]'s ????
AM I going about this the wrong way....
ie, all I want to do is accept mail from the Internet for my domain, apply
the new spam filters and protection afforded in sendmail 8.9.1, forward all
mail to an internal host that has an old mail implementation (that does not
protect it from spammers etc..) and relay mail from that (and other) hosts
back out to the 'net?
(as a friend commented today, I am only in my first phase of coming to grips
with sendmail --> I @#$#$ hate it!, hopefully soon the veil will be lifted
and I will love it)
sincerely, Ian Ward.