Does anybody know how this function can be disabled, either at compile
time or in config later? (For speed I'd prefer to not even do the
lookups, but doing and not acting on them would be okay too.) I want to
restrict relaying based ONLY on my access database.
Thanks,
--
Brent Emerson | Messaging Support Lead | Pilot Network Services
No, that isn't correct, it will happily accept (and relay if
appropriately configured) even if A(PTR(IP)) != IP. What it won't do in
that case, for obvious reasons, is to allow relaying based on the SMTP
client's host/domain name - i.e. you need to have the IP address/net in
access db.
--Per Hedeland
p...@bluetail.com
That's wrong; mail acceptance is NOT based on this check.
> not relay, with different error messages depending on whether the
That's wrong too, all this does is whether the hostname will be
used for a decision wrt relaying. The reason should be obvious.
> initial PTR record didn't exist or whether it existed but the A record
> for the PTR record didn't exist or didn't match the original IP.
> Does anybody know how this function can be disabled, either at compile
> time or in config later? (For speed I'd prefer to not even do the
> lookups, but doing and not acting on them would be okay too.) I want to
> restrict relaying based ONLY on my access database.
Relaying is denied by default.
So you can't restrict it any further, you can only allow it.
If you allow relaying based on IP addresses you won't have
any problem with wrong DNS entries.
What's the exact problem you're trying to solve?
--
If you feel the urgent wish to send me a courtesy copy of a Usenet
posting, then make sure it's recognizable as such!
The FAQ: http://www.sendmail.org/faq/ Before you ask.
ok, then what does this mean:
Jan 2 00:55:33 mailhost sendmail[6288]: f028tXw06288:
ruleset=check_rcpt,
arg1=<us...@a.local.domain>, relay=unknown-AAA-BBB-CCC-DDD.our.domain
[AAA.BBB.CCC.DDD] (may be forged), reject=550 5.7.1
<us...@a.local.domain>... Relaying denied. IP name possibly forged
[AAA.BBB.CCC.DDD]
when the line
AAA.BBB OK
OR
AAA.BBB RELAY
is in my access db ?
> What's the exact problem you're trying to solve?
Want to deny ALL relaying, except accept:
(a) mail from ANYWHERE for one of the RELAY domains in my access db
(b) mail to ANY DOMAIN from one of the local RELAY hosts or nets in my
access db
Occasional hosts who have less-than-perfect reverse DNS configs are
failing this check_rcpt rule, even though their IP or network is listed
in the access db. I have no explanation for why this is occurring
except for the reverse DNS thing.
???
: > Brent Emerson wrote:
: > > By default sendmail 8.11.2 seems to do reverse DNS lookups to decide
: > > whether to accept mail from a host or not. If A(PTR(IP)) != IP, it will
: >
: > That's wrong; mail acceptance is NOT based on this check.
: ok, then what does this mean:
: arg1=<us...@a.local.domain>, relay=unknown-AAA-BBB-CCC-DDD.our.domain
: [AAA.BBB.CCC.DDD] (may be forged), reject=550 5.7.1
: <us...@a.local.domain>... Relaying denied. IP name possibly forged
: [AAA.BBB.CCC.DDD]
:
: when the line
: AAA.BBB OK
: OR
: AAA.BBB RELAY
: is in my access db ?
So what is in your access DB? The first entry or the second?
Only the second allows relaying.
Please give a real example and I tell you what's wrong.
For a start: run
echo '/map access AAA.BBB' | sendmail -bt
: Want to deny ALL relaying, except accept:
: (a) mail from ANYWHERE for one of the RELAY domains in my access db
That works fine.
: (b) mail to ANY DOMAIN from one of the local RELAY hosts or nets in my
: access db
: Occasional hosts who have less-than-perfect reverse DNS configs are
: failing this check_rcpt rule, even though their IP or network is listed
: in the access db. I have no explanation for why this is occurring
: except for the reverse DNS thing.
There are two solutions:
1. Fix DNS.
2. Use the IP addresses or nets.
As I wrote before: sendmail won't use a probably faked domain name
otherwise spammers could easily circumvent relay protection.
Right. This is why I of course use IP addresses and nets in the access
db. I figured out what was wrong -- because the hosts' IP addresses
were not in the /etc/relay-domains file, they were being looked up in
DNS, presumably to determine whether they were allowed by the access
db. So what I thought was a reverse-lookup-to-allow-relaying was in
fact a reverse-lookup-to-check-the-access-file-by-domin-name. Now I
understand your comments.
So I can solve this problem by adding all the IPs I want to be allowed
to relay openly to the /etc/relay-domains file, which is nice, but it
expands my question -- what is the difference between "143.144.175.54"
in the /etc/relay-domains file and "143.144.175.54 RELAY" as a line in
the access database? I feel like I'm missing some central difference,
becuase I don't understand the purpose of relay-domains when we have the
access database.
Can you shed some light, Claus?
>So I can solve this problem by adding all the IPs I want to be allowed
>to relay openly to the /etc/relay-domains file, which is nice, but it
>expands my question -- what is the difference between "143.144.175.54"
>in the /etc/relay-domains file and "143.144.175.54 RELAY" as a line in
>the access database?
If you are also using the orbs blocking list with dnsbl, and if
143.144.175.54 is in the orbs list, then the access database entry
will allow you to still accept and relay this mail. With the
relay-domains entry alone the mail would be blocked by the orbs
listing. (Orbs is just an example; the same applies to any dnsbl
blocking list).
>becuase I don't understand the purpose of relay-domains when we have the
>access database.
relay-domains is supposed to provide a simple way if specifying a
blanket class of local hosts/ip addresses for which you will
standardly relay. The access_db is intended to give finer
control.