Block all incoming except one IP address
Jim Stewart
my MX records to and that forwards non-spam to
my sendmail box. Unfortunately, a significant
number of spammers are presumeably ignoring the
current MX record and are sending mail to the
old MX record.
How do I configure sendmail to ignore everything
that isn't coming from the Barracuda ip address?
Andrzej Adam Filip
Block 256 */8 nets.
connect:aaa.bbb.ccc.ddd OK
connect:0 REJECT
connect:1 REJECT
....
connect:255 REJECT
--
[pl2en Andrew] Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
http://www.sendmail.org/faq/ http://anfi.homeunix.net/sendmail/
Before You Ask: http://anfi.homeunix.net/sendmail/B4UAsk-Sendmail.html
Jim Stewart
> Jim Stewart <jste...@jkmicro.com> writes:
>
>
>>I have a Barracuda spam filter that I've pointed
>>my MX records to and that forwards non-spam to
>>my sendmail box. Unfortunately, a significant
>>number of spammers are presumeably ignoring the
>>current MX record and are sending mail to the
>>old MX record.
>>
>>How do I configure sendmail to ignore everything
>>that isn't coming from the Barracuda ip address?
>
>
> Block 256 */8 nets.
>
> connect:aaa.bbb.ccc.ddd OK
> connect:0 REJECT
> connect:1 REJECT
> ....
> connect:255 REJECT
I hate to be a pain, but could you comment it
for me?
Andrzej Adam Filip
Sendmail supports blocking on octet boundaries ( */8, */16, */24, */32).
You can block all 256 */8 nets and make exception (hole) for "the ip".
URL(s):
http://www.sendmail.org/m4/anti_spam.html#access_db
Robert Harker
the prefix tag connect: indicates the entry will be used in the
check_relay ruleset which is called when an SMTP client
connects to sendmail
> connect:123.456.789.123 OK
This entry tells sendmail that an SMTP connection from
the IP address 123.456.789.123 is allowed.
> connect:0 REJECT
> connect:1 REJECT
> ...
> connect:255 REJECT
These entries tell sendmail to not accept mail from
P addresses starting with the class A net block (/8)
starting with 0, 1, . . . , 255
Hope this helps
RLH
For info about our "Managing Internet Mail, Setting Up and Trouble
Shooting sendmail and DNS" and "Advanced Topics In Sendmail:
Performance Tuning, LDAP Integration and Spam Control" seminars,
and a schedule of dates and locations, please send email to
in...@harker.com, or visit www.harker.com
Jim Stewart
>>I hate to be a pain, but could you comment it for me?
>
>
> the prefix tag connect: indicates the entry will be used in the
> check_relay ruleset which is called when an SMTP client
> connects to sendmail
>
>
>>connect:123.456.789.123 OK
>
>
> This entry tells sendmail that an SMTP connection from
> the IP address 123.456.789.123 is allowed.
>
>
>>connect:0 REJECT
>>connect:1 REJECT
>>...
>>connect:255 REJECT
>
>
> These entries tell sendmail to not accept mail from
> P addresses starting with the class A net block (/8)
> starting with 0, 1, . . . , 255
>
> Hope this helps
It does. One more stupid question,
must I type in 255 unique lines of
connect:0, connect:1, etc or will
sendmail understand the 4 lines above
to mean everything between 0 and 255?
Andrzej Adam Filip
Sendmail is not that smart :-)
4 enties will not be enough.
BTW make also "exception" for 127.0.0.1
If you want to use *ONE* entry then use "presprocessing" described in
the FAQ:
http://www.sendmail.org/faq/section3.html#3.41
Q3.41 -- How do I use CIDR notation in the access map (or other places)?
Per Hedeland
Actually you need two entries (besides the "exceptions") - cidrexpand
(or rather Net::CIDR) doesn't "understand" 0.0.0.0/0 (the "old"
Net::CIDR-less cidrexpand in sendmail 8.12.x contrib, with x >= 7,
*does* understand it).
--Per Hedeland
p...@hedeland.org
jma...@ttec.com
Aside from Per's suggestion there are two other ways.
1)
Modify the proto.m4 file used to rebuild sendmail.cf so that after
looking for access entries it then performs a reject for all unfound
entries
Surround your mods with m4 ifdef's and now you can turn it on or off in
the sendmail.mc
You should maintain this mod as a local patch to sendmail.
2)
Copy and modify the rulesets used to perform the access table lookups
so that they look for a key that is tag with no value, and treat it as
the final "Default" lookup.
Hook that into local_check_rcpt or local_check_connect or similar.
Something like this is how I did it somewhere once
(convert space into tab between LHS and RHS)
Saccess_default
#R<><$+><> $: $>A_Default < > <?> <+ $1> <>
R<><$+><> $: $>SearchList <! $1> $| <E:> <>
R<?> $* $@ OK found nothing
R<$={Accept}> $* $@ $1 return value of
lookup
R<REJECT> $* $#error $@ 5.7.1 $: "550 Access denied"
R<DISCARD> $* $#discard $: discard
R<ERROR:$-.$-.$-:$+> $* $#error $@ $1.$2.$3 $: $4
R<ERROR:$+> $* $#error $: $1
R<$* <TMPF>> $* $#error $@ 4.3.0 $: "451 Temporary system
failure. Please try again later."
R<$+> $* $#error $: $1
Per Hedeland
"jma...@ttec.com" <jma...@ttec.com> writes:
>
>Jim Stewart wrote:
>> I have a Barracuda spam filter that I've pointed
>> my MX records to and that forwards non-spam to
>> my sendmail box. Unfortunately, a significant
>> number of spammers are presumeably ignoring the
>> current MX record and are sending mail to the
>> old MX record.
>>
>> How do I configure sendmail to ignore everything
>> that isn't coming from the Barracuda ip address?
>
>Aside from Per's suggestion there are two other ways.
I think the suggestion was Andrzej's, but it's the standard one(s).
>1)
[ snip local mod to sendmail distribution files ]
>2)
[ snip putting a bunch of rules that were once based on sendmail.cf
contents into sendmail.mc - a local mod, only not visibly so ]
Well, lots of things are *possible*, but do you really think either of
those has any advantage over a one-time
perl -le 'foreach $i (1..255) { print "connect:$i REJECT" }' >> access
(or the cidrexpand alternative for that matter)? Close to zero
implementation time, zero testing and maintenance time, is hard to beat.
--Per Hedeland
p...@hedeland.org
Andrzej Adam Filip
> [...]
Do you think it would be "cost effective" to introduce "default" per
access db prefix replies (optionally hardcoded) in sendmail.cf?
One ferson have asked for default reject based on envelope sender
(from:*). Questions about "connect:*" are quite common.
jma...@ttec.com
Per Hedeland wrote:
> In article <1144324264....@e56g2000cwe.googlegroups.com>
> "jma...@ttec.com" <jma...@ttec.com> writes:
> >
> >Aside from Per's suggestion there are two other ways.
>
> I think the suggestion was Andrzej's, but it's the standard one(s).
Apologies to Per and Andrzej for mixing you two, completely my fault
for not being carefull, even though you both are pretty prolific.
> >2)
>
> [ snip putting a bunch of rules that were once based on sendmail.cf
> contents into sendmail.mc - a local mod, only not visibly so ]
>
> Well, lots of things are *possible*, but do you really think either of
> those has any advantage over a one-time
Well from a design standpoint its a solution that has a much tighter
fit to the problem.
And whats your suggestion to deal with ipv6?
Also this is real easy to turn on an off. Plus you can extend it to ANY
tag.
jma...@ttec.com
Per Hedeland wrote:
> In article <1144324264....@e56g2000cwe.googlegroups.com>
> "jma...@ttec.com" <jma...@ttec.com> writes:
[bad form to reply twice. Apologies to all]
>
> [ snip local mod to sendmail distribution files ]
I cant be the only one that runs sendmail with local patches. Whats one
more? And a trivial one at that.
>
> >2)
>
> [ snip putting a bunch of rules that were once based on sendmail.cf
> contents into sendmail.mc - a local mod, only not visibly so ]
Putting rulesets into sendmail.mc and hooking it into the local_check_*
is the recommended and preferred way for local customization, last I
checked.
And imitation is the sincerest form of flattery, which is why I hunted
down the sendmail ruleset that best matched my need. Perhaps I should
have maintained that as a local patch, enabling the sendmail ruleset to
check default result of each tag as well.
And as far as tags are concerned, the * is redundant. Simply leaving
the portion after the key better describes the desired match --
everything for this tag.
>
> Well, lots of things are *possible*, but do you really think either of
> those has any advantage over a one-time
>
> perl -le 'foreach $i (1..255) { print "connect:$i REJECT" }' >> access
>
> (or the cidrexpand alternative for that matter)? Close to zero
> implementation time, zero testing and maintenance time, is hard to beat.
Its not elegant. Inelegant solutions are bugs waiting to be realized.
Yes, I am from that school of thought.
Think about all the ways people like to actually use an access
database. Think about the people who have to use it who oftentimes have
no idea what perl is. Think about the web front ends and the ldap
backends and so on so forth.
Per Hedeland
"jma...@ttec.com" <jma...@ttec.com> writes:
>
>Per Hedeland wrote:
>> In article <1144324264....@e56g2000cwe.googlegroups.com>
>> "jma...@ttec.com" <jma...@ttec.com> writes:
>
>[bad form to reply twice. Apologies to all]
Accepted:-) - but I'll only reply to one of them...
>> [ snip local mod to sendmail distribution files ]
>
>I cant be the only one that runs sendmail with local patches. Whats one
>more? And a trivial one at that.
No, I'm sure you're not the only one - but I think overall it's unusual,
and for good reasons - maintaining local mods across upgrades is always
a pain, to a bigger or lesser extent. Sometimes there's no alternative
though - but this isn't one of those cases.
>> [ snip putting a bunch of rules that were once based on sendmail.cf
>> contents into sendmail.mc - a local mod, only not visibly so ]
>
>Putting rulesets into sendmail.mc and hooking it into the local_check_*
>is the recommended and preferred way for local customization, last I
>checked.
Obviously I was not commenting on putting rules into sendmail.mc per se
- but even this should maybe be avoided if possible, at least for the
typical user that doesn't really understand how the rules work, but has
just cut'n'pasted them from a newsgroup posting. And when the rules use
undocumented interfaces and require careful scrutiny of sendmail.cf to
really understand, warning lights should really pop up.
This is a perfectly fine thing for *you* to do, and it would be
perfectly fine for me too - for private systems, where I'm sure that
no-one else will one day have figure out what that stuff is all about.
Suggesting it as a generally useful solution in response to a newbie
question (apologies to the OP) borders on irresponsible IMHO.
>> Well, lots of things are *possible*, but do you really think either of
>> those has any advantage over a one-time
>>
>> perl -le 'foreach $i (1..255) { print "connect:$i REJECT" }' >> access
>>
>> (or the cidrexpand alternative for that matter)? Close to zero
>> implementation time, zero testing and maintenance time, is hard to beat.
>
>Its not elegant. Inelegant solutions are bugs waiting to be realized.
>Yes, I am from that school of thought.
I'd say elegance is in the eye of the beholder - and in my eye things
like an overly complex solution using methods that for the vast majority
of users are obscure or even totally incomprehensible, when standard
tools can provide a trivial solution, does not give any positive points
on the elegance scale.
And "bugs waiting to be realized" is really hilarious here - I'm
confident that the one-liner above will continue to work correctly as
long as there exists a program called perl and sendmail uses an access
database - whereas your solution could become a bug with the next
sendmail patch release.
>Think about all the ways people like to actually use an access
>database. Think about the people who have to use it who oftentimes have
>no idea what perl is. Think about the web front ends and the ldap
>backends and so on so forth.
And the people who can't maintain a text file or know what perl is will
be comfortable with a bunch of sendmail rewrite rules that may break at
any upgrade - right...
--Per Hedeland
p...@hedeland.org
jma...@ttec.com
> In article <1144416026.6...@g10g2000cwb.googlegroups.com>
> "jma...@ttec.com" <jma...@ttec.com> writes:
> >
>
> Obviously I was not commenting on putting rules into sendmail.mc per se
> - but even this should maybe be avoided if possible, at least for the
> typical user that doesn't really understand how the rules work, but has
> just cut'n'pasted them from a newsgroup posting. And when the rules use
> undocumented interfaces
Searchlist and Accept
Yes, very undocumented and likely to change at a moments notice.
> and require careful scrutiny of sendmail.cf to
> really understand, warning lights should really pop up.
>
To steer the discussion back to practical purposes:
Is there any reason NOT to have the sendmail access lookup routines
accept a blank value tag as a default?
Its been a while, but I do think it is a trivial change.
> This is a perfectly fine thing for *you* to do, and it would be
> perfectly fine for me too - for private systems, where I'm sure that
> no-one else will one day have figure out what that stuff is all about.
> Suggesting it as a generally useful solution in response to a newbie
> question (apologies to the OP) borders on irresponsible IMHO.
>
And to those, I second the admonishment: If you are not ever prepared
to read rulesets and attempt to understand them when faced with the
need, dont use it and/or dont do it yourself.
Come to think of it, that could apply for most things.
Some sites may have an admin/hacker/consultant/ubergeek that sets the
system up and maintains its "inner" workings and they also have
operaters who operate the switches and levers and dont understand the
system much anyways. Which way do you think those sites would prefer?
What do you think the admin would prefer to tell the operators about
how to control these features?
> >> Well, lots of things are *possible*, but do you really think either of
> >> those has any advantage over a one-time
> >>
> >> perl -le 'foreach $i (1..255) { print "connect:$i REJECT" }' >> access
> >>
> >> (or the cidrexpand alternative for that matter)? Close to zero
> >> implementation time, zero testing and maintenance time, is hard to beat.
> >
> >Its not elegant. Inelegant solutions are bugs waiting to be realized.
> >Yes, I am from that school of thought.
>
> I'd say elegance is in the eye of the beholder - and in my eye things
> like an overly complex solution using methods that for the vast majority
> of users are obscure or even totally incomprehensible, when standard
> tools can provide a trivial solution, does not give any positive points
> on the elegance scale.
>
Elegance is all about moving the complexity to where it belongs. Not
about eliminating it.
And yes you are right, it is all in the eye of the beholder anyways and
this is rather pointless. My apologies for bringing it up.
> And "bugs waiting to be realized" is really hilarious here - I'm
> confident that the one-liner above will continue to work correctly as
> long as there exists a program called perl and sendmail uses an access
> database - whereas your solution could become a bug with the next
> sendmail patch release.
If the maintainers of a system decide to customize the system for local
purposes, than they might also prefer this way.
Might I request you also post your one liner to extend the solution for
ipv6?
>
> >Think about all the ways people like to actually use an access
> >database. Think about the people who have to use it who oftentimes have
> >no idea what perl is. Think about the web front ends and the ldap
> >backends and so on so forth.
>
> And the people who can't maintain a text file or know what perl is will
> be comfortable with a bunch of sendmail rewrite rules that may break at
> any upgrade - right...
The operators will be comfortable with a procedure list that states
"Control X by commenting or uncommenting out this line in this file"
Quite possibly they will not be comfortable with a procedure that
involves more than two lines anywhere or running any sort of program
and doing something with its output.
The operators would not be performing the upgrades in these scenarios.
>
> --Per Hedeland
> p...@hedeland.org
Claus Aßmann
> Is there any reason NOT to have the sendmail access lookup routines
> accept a blank value tag as a default?
It depends. In this case: yes. The main purpose of the MTA is to
receive mail, not to reject everything by default. Hence it would be
one additional lookup for everyone with a "normal" setup (which can be
slow depending on your map type). Those who want to reject everything
should use a firewall (every modern OS has one), that's way more
efficient. Just use the right tool(s) for the job. Why do you want to
fork a sendmail process just to give some errors back to the client?
jma...@ttec.com
If you have different servers for submission and MX, and you do not
restrict your submission server to auth clients, but also to "network
source" authenticated, port 25, pop b4 smtp and whatever other
permissive rulesets/features you use, you also want all else to be
denied with something like this:
Connect: ERROR:5.7.1:"\nThis is not our MX and
you are not detected as authorized to use this server.\nPlease call in
to our support if you wish to arrange for authorization."
And yes, this does get hit quite often by spammers and what not. Never
authorized clients.
In these cases it is always only sendmail that will know if the
connection is to proceed or if it is to be returned with the default
lookup of rejected.
So if the concern is the extra lookup, perhaps it being an _FFR_ should
suffice.
Andrzej Adam Filip
> [...]
> To steer the discussion back to practical purposes:
>
> Is there any reason NOT to have the sendmail access lookup routines
> accept a blank value tag as a default?
The practical reason is to reduce number of required access table lookups.
It would be possible put default values directly in sendmail.cf
(no need for extra lookup).
BTW it is possible to drastically reduce number of required access table
lookups but it would require using specific map (btree based searches)
instead of "general map" (any map).
Per Hedeland
"jma...@ttec.com" <jma...@ttec.com> writes:
>
>Some sites may have an admin/hacker/consultant/ubergeek that sets the
>system up and maintains its "inner" workings and they also have
>operaters who operate the switches and levers and dont understand the
>system much anyways. Which way do you think those sites would prefer?
>What do you think the admin would prefer to tell the operators about
>how to control these features?
I think that's entirely beside the point - either method can be switched
on/off by the click of a GUI button. I.e. obviously such operators
wouldn't run perl commands appending to a text file, the ubergeek would
implement that as an (e.g.) environment-variable-dependant component of
the Makefile that creates the final access db when the operator clicks
"go" - and the ubergeek wouldn't need to worry about problems with
custom rewrite rules.
>And yes you are right, it is all in the eye of the beholder anyways and
>this is rather pointless. My apologies for bringing it up.
And I guess I should apologize too, I was over-reacting a bit - of
course you should present your idea of the optimal solution, and we
should let whoever needs this thing make a hopefully informed choice.
I just couldn't help finding it bizarre to see sendmail source mods and
a bunch of custom rules presented as alternatives to the trivial (if
non-obvious) solution already posted.
>Might I request you also post your one liner to extend the solution for
>ipv6?
Sure - I must confess that I haven't looked into using IPv6 addresses in
sendmail tables before, but I assume this would do the trick:
perl -e 'foreach $i (1..65535) { printf "Connect:IPv6:%04x REJECT\n", $i }'
And no, I wouldn't be concerned about having 64k entries in access db -
but the fact that sendmail will need, what, 8 lookups to find these
entries should probably be a concern. As should of course the fact that
it needs 8 lookups to find that there isn't an entry at all. Still, it's
slightly better than the 9 lookups needed to find a default value...
--Per Hedeland
p...@hedeland.org
Martin
I've tested this solution (connect:0 REJECT .. connect:255 REJECT).
It works but I get the "Access denied" after "Helo" and "Mail from:".
Is it possible to change the "Connect:"-Behavior in order
to get to "Access denied" before "Helo" ?
Isn't the build-in tcp wrapper the best solution for
"Block all incoming except one IP address" ?
Unlike the "connect:.."-solution you don't have
a lot of access queries (that's a performance issue
when using LDAP queries) and unlike iptables firewall
you will get a SMTP-Error-Message "550 Access denied".
Martin
Andrzej Adam Filip
SMTP protocol specification allows to reject incoming connection in SMTP
greeting message. sendmail-8 (so far) does not support such
functionality. It has been mentioned in discussion about the best way to
block dynamic IP addresses.
Feel free to contribute the patch.
Use the force, change the (open) source! :-)
URL(s):
http://www.sendmail.org/misc/email-addresses.html
Per Hedeland
<ug2...@mail.lrz-muenchen.de> writes:
>
>Isn't the build-in tcp wrapper the best solution for
>"Block all incoming except one IP address" ?
>Unlike the "connect:.."-solution you don't have
>a lot of access queries (that's a performance issue
>when using LDAP queries) and unlike iptables firewall
>you will get a SMTP-Error-Message "550 Access denied".
Claiming that something is unconditionally "best" is almost always
problematic, as some discussion in another part of this thread might
indicate:-) - but builtin tcp-wrappers is a perfectly fine solution for
that problem, for the reasons you mention (and it also avoids putting a
lot of "silly" entries in the access file, for those that care about
that:-). If it suits your needs, go ahead and use it...
--Per Hedeland
p...@hedeland.org
Andrzej Adam Filip
AFAIK post people prefer to use "packaged" sendmail provided by OS
distribution they use. TCPWRAPPERS support is not compiled in all
precompiled sendmail "packages".
jma...@ttec.com
I use them too.
However it does precude the ability to allow connections from that IP
address when their are authenticated or when they have recently POP'd
or so on so forth. For that, you may want to use the extensive
faciltities provided by sendmail rulesets to allow the smtp daemon to
control things with a fine toothed comb.
Of course, if the poster is describing a situation where this is not a
concern, go for it.
You might need to to recompile sendmail.
/usr/sbin/sendmail -d0.10 -bv root
See if it mentions TCPWRAPPERS if it does you are in the clear.
Rob Stampfli
Here's how I did it:
(1) My home sendmail listens externally on a nonstandard port.
I'll leave it as an exercize for the reader to figure out how
to make this happen. (It was easiest for me just to remap the
port in my firewall.)
In the sending system's (the one w/the spam filter) sendmail.mc
file:
define(`confRELAY_MAILER', `esmtp')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 12345')dnl where 12345 is the non-std port
Then in the sending system's /etc/mail/mailertable:
mydomain.com: relay:[IP.of.my.home.system]
(2) Just in case that is not enough, in my home system's
sendmail.mc file, I added:
FEATURE(`greet_pause', `127506841')dnl (largest non-neg int, good for 35+hrs)
Then in my home system's /etc/mail/access file, I added
the IPs that I am willing to accept mail from:
GreetPause:127 0
GreetPause:192.168 0
GreetPause:mymailserver.com 0
YMMV,
Rob
Martin
Now I have tested the sendmail build-in TCP Wrapper,
it works on principle but unfortunately it's a
disappointment:
* Like the access mapping the "Access Denied" comes after "Mail from:"
and not at the beginning of the connection (before "Helo").
* Although there is an entry for "a.b.c.d." in hosts.deny
I can see additionally ldap access map queries in my logfile
for this IP address. Ok, the hosts.deny solution works, but what
is the sense of this tautologous query ?
Martin