I've domain kemerovo.su that has many third-level subdomains
each of which has own MX record, most of records point
to my sendmail-powered relay having 'kemerovo.su' record in its
relay-domains file.
I have no 'relay_hosts_only' feature in my sendmail.mc file,
so it receives mail for every subdomain. Sadly, it receives
mail for non-existing domains too. Note, there is no asterisk (*)
in the kemerovo.su zone. So, sendmail queues incoming mail for
non-existing subdomains and then sends DSN with 'host unknown' error.
How do I prevent it from doing such BadThing (TM)?
The list of subdomains is ever changing so I'd rather not to use
FEATURE(relay_hosts_only)... And I don't like FEATURE(relay_based_on_MX) too.
Just need to stop it to accept mail for non-existing domains.
I run 8.13.3 but may upgrade to 8.14.x if absolutely needed.
Eugene Grosbein
You *should* list explicitly all relay-able (sub-)domain *AND* list all
valid email addresses in the domains to avoid relaying mail (spam) to
non existing recipients.
To get exactly what you request I would recommend a few lines patch of
Rcpt_ok rule set in cf/m4/proto.m4 file.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : an...@xl.wp.pl
I think we are in Rats' Alley where the dead men lost their bones.
-- T.S. Eliot
AAF> You *should* list explicitly all relay-able (sub-)domain
There are too much of them, several hundreds, and list changes in time...
I'd rather not to do that, just make sendmail to not accept mail
for non-existing domains. Do I want too much?
AAF> To get exactly what you request I would recommend a few lines patch of
AAF> Rcpt_ok rule set in cf/m4/proto.m4 file.
Thanks. Could you please show an example? I'm not good in writing rulesets.
Eugene Grosbein
Its not like you have to hardcode the names into a program. You
put them in a file and restart sendmail. Otherwise, what method is
sendmail supposed to use to decide if its valid or not? An alternative
is the "relay_based_on_MX", but I think you mentioned you didn't want
to use that either. You gotta help out sendmail SOMEHOW.......
I also think I saw something about UUCP in the mix. If your
UUCPing to the sites, not sure how you do it, but we do it (Yea, we
UUCP. Yes, I know its the 21st century. And I use elm too, what of
it?? ;) ) by putting an entry in mailertable and remaking the file. If
you have to maintain that file, then script something to hack it up
and put into the relay-domains table and
kill -1 `cat /var/run/sendmail.pid | cut -d/ -f1`
Tuc
AAF>> You *should* list explicitly all relay-able (sub-)domain
>> There are too much of them, several hundreds, and list changes in time...
>> I'd rather not to do that, just make sendmail to not accept mail
>> for non-existing domains. Do I want too much?
T> Its not like you have to hardcode the names into a program. You
T> put them in a file and restart sendmail. Otherwise, what method is
T> sendmail supposed to use to decide if its valid or not?
Exactly the same method it uses to check sender domain -
it checks if it exists in DNS.
T> An alternative
T> is the "relay_based_on_MX", but I think you mentioned you didn't want
T> to use that either. You gotta help out sendmail SOMEHOW.......
I do - I put domains in DNS (MX records, to be exact).
T> I also think I saw something about UUCP in the mix. If your
T> UUCPing to the sites, not sure how you do it, but we do it (Yea, we
T> UUCP. Yes, I know its the 21st century. And I use elm too, what of
T> it?? ;) ) by putting an entry in mailertable and remaking the file.
So do I :-)
T> If you have to maintain that file, then script something to hack it up
T> and put into the relay-domains table and
T> kill -1 `cat /var/run/sendmail.pid | cut -d/ -f1`
There is better way: explicitly note all the domain itself and all
existing subdomains in the access file and use FEATURE(relay_hosts_only),
so sendmail won't accept mail for other subdomains (non-existing).
This way there is no need to restart sendmail after changes as it rereads
access.db dynamically. But I think this should not be needed,
sendmail already checks sender domain, why does not it do that for target?
Eugene Grosbein
Ok... So why not update the Access DB while you are at it?
> There is better way: explicitly note all the domain itself and all
> existing subdomains in the access file and use
> FEATURE(relay_hosts_only), so sendmail won't accept mail for other
> subdomains (non-existing). This way there is no need to restart
> sendmail after changes as it rereads access.db dynamically. But I
> think this should not be needed, sendmail already checks sender
> domain, why does not it do that for target?
For giggles and grins, try /temporarily/ removing the MX record for your
parent domain and see if Sendmail continues to accept email for invalid
and / or non-existent sub-domains.
Grant. . . .
AAF> To get exactly what you request I would recommend a few lines patch of
AAF> Rcpt_ok rule set in cf/m4/proto.m4 file.
How about this? I've added this to my .mc and it seems to work nice:
LOCAL_CONFIG
SLocal_check_rcpt
R$* $: $>Parse0 $>3 $1
R$+<@$+> $: <all>$1<@$2>
R<all>$+<@$+.> $: $1<@$2.>
R<all>$+ $#error $: "553 5.1.8 Domain of recipient address does not exist."
Eugene Grosbein
AAF>> To get exactly what you request I would recommend a few lines patch of
AAF>> Rcpt_ok rule set in cf/m4/proto.m4 file.
EG> How about this? I've added this to my .mc and it seems to work nice:
EG> LOCAL_CONFIG
EG> SLocal_check_rcpt
Forget, it does not work :-(
Eugene Grosbein
Start with testing changes directly in sendmail.cf.
0) copy sendmail.cf to sendmail-test.cf
1) modify sendmail-test.cf
*Do remember* to put TABs (\t) between left-hand-side and
right-hand-side of "R" lines
*ORIGINAL*
R$+ < @ $* $=3DR > $@ RELAY
*MODIFIED*
# relay top $=3DR domains without any additional checks
R$+ < @ $=3DR > $@ RELAY
# check recipient domain in DNS
R$+ < @ $* $=3DR > $: <? $(resolve $2$3 $: $2$3 <PERM> $)> $1 <@$2$3 >
R<? $* <$->> $* < @ $+ > $: <? $2> $3 < @ $4 >
# resolved OK =3D> relay
R<? OKR> $* < @ $+ > $@ RELAY
# temporary error =3D> wait
R<? TEMP> $* < @ $+ > $#error $@ 4.3.0 $: "451 Temporary system failure. P=
lease try again later."
permanent error =3D> reject
R<? PERM> $* < @ $+ > $#error $@ 5.7.1 $: "550 Access denied"
R<? $*> $* < @ $+ > $: $2 < @ $3 >
2) conduct initial test using the script below
#!/bin/sh
/usr/sbin/sendmail -C /etc/mail/sendmail-test.cf -d21.12 -d60.1 -bt <<END
# set client address
.D{client_addr}10.0.0.1
Rcpt_ok user < @ the.domain >
END
3) Do not try it on production server before getting independent
confirmation that "it may work" from somebody you trust
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : an...@xl.wp.pl
The only winner in the War of 1812 was Tchaikovsky.
-- David Gerrold
Start with testing changes directly in sendmail.cf.
0) copy sendmail.cf to sendmail-test.cf
1) modify sendmail-test.cf
*Do remember* to put TABs (\t) between left-hand-side and
right-hand-side of "R" lines
*ORIGINAL*
R$+ < @ $* $=R > $@ RELAY
*MODIFIED*
# relay top $=R domains without any additional checks
R$+ < @ $=R > $@ RELAY
# check recipient domain in DNS
R$+ < @ $* $=R > $: <? $(resolve $2$3 $: $2$3 <PERM> $)> $1 <@$2$3 >
R<? $* <$->> $* < @ $+ > $: <? $2> $3 < @ $4 >
# resolved OK => relay
R<? OKR> $* < @ $+ > $@ RELAY
# temporary error => wait
R<? TEMP> $* < @ $+ > $#error $@ 4.3.0 $: "451 Temporary system failure. Please try again later."
# permanent error => reject
R<? PERM> $* < @ $+ > $#error $@ 5.7.1 $: "550 Access denied"
R<? $*> $* < @ $+ > $: $2 < @ $3 >
2) conduct initial test using the script below
#!/bin/sh
/usr/sbin/sendmail -C /etc/mail/sendmail-test.cf -d21.12 -d60.1 -bt <<END
# set client address
.D{client_addr}10.0.0.1
Rcpt_ok user < @ the.domain >
END
3) Do not try it on production server before getting independent
confirmation that "it may work" from somebody you trust
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : an...@xl.wp.pl
Romance, like alcohol, should be enjoyed, but should not be allowed to
become necessary.
-- Edgar Friedenberg
AAF>> You *should* list explicitly all relay-able (sub-)domain
>> There are too much of them, several hundreds, and list changes in time...
>> I'd rather not to do that, just make sendmail to not accept mail
>> for non-existing domains. Do I want too much?
RD> Yes. You already have to maintain all those system names in DNS, why not
RD> simply add them to the relay domains file at the same time? You just
RD> need to extend your management system slightly.
I can easily do this but love to avoid, it does not seem right to me.
Eugene
<scratching head>
Ok...
</scratching head>
<hands up in the air>
I guess you are entitled to your own opinion(s). Just be aware that
(to the best of my knowledge) they differ from most other peoples.
</hands up in the air>
Grant. . . .
OK, I somewhat understand this. If you check the domain each time a
mail comes in, you query the DNS each time. OK, it's cached, but you
add more work.
I guess, this is a pure relay, right? How do you reject unknown
recipients to a valid domain? If you do not do it on the incoming
server, you generate bounce messages.
If you validate users, you validate domains out of the box.
ska
s> OK, I somewhat understand this. If you check the domain each time a
s> mail comes in, you query the DNS each time. OK, it's cached, but you
s> add more work.
There is local caching DNS server.
s> I guess, this is a pure relay, right? How do you reject unknown
s> recipients to a valid domain? If you do not do it on the incoming
s> server, you generate bounce messages.
s> If you validate users, you validate domains out of the box.
If domain exists in DNS then there is a record in mailertable
diverting mail to UUCP for this domain. There is no need to validate domain
and there are no bounces and there is no such thing as unknown recipient
in existing domain :-)
Eugene
s> OK, I somewhat understand this. If you check the domain each time a
s> mail comes in, you query the DNS each time. OK, it's cached, but you
s> add more work.
No, there is less work: domain will be checked anyway
(remember DSN with 'host unknown' error), but we eliminate receiving
of message body and queueing it.
Eugene
Tuc
Have you considered using (perl) script(s) to generate matching
mailertable and access table (to:xxx RELAY) entries for the sub-domains?
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : an...@xl.wp.pl
Life is like an onion: you peel off layer after layer and then you find
there is nothing in it.
-- James Huneker
T> and about 64K RBL blocked messages a day.
My own private RBL blocks about 300K messages a day not counting
mail from hosts automatically blocked at firewall level for abusing
RBL too much :-) However, this is outside of thread's topic.
Eugene
AAF> Have you considered using (perl) script(s) to generate matching
AAF> mailertable and access table (to:xxx RELAY) entries for the sub-domains?
Yes, that's pretty easy. However, I beleive that should not be needed.
Eugene
--
WallJam7: roses are red
WallJam7: violets are blue
WallJam7: all of my base
WallJam7: are belong to you // www.bash.org.