How to reject mail at external gateway not internal
Scott Field
The external has a mailertable entry for my domain, and it sends all
mail for the domain to the internal server. The whole thing works fine.
I would like to block mail to certain users in my domain that no longer
exist
in the system because they have left the company, at the external
gateway.
Currently mail for the non-existent users comes to the internal server,
which
rejects the user, bounces the message back to a non-existent spammer
address,
that fails, then I get a notification as postmaster. I'd like to avoid
all that.
However on the external machine, the mailertable entry seems to take
precedence
over any sendmail database configuration (virtual user, access etc) that
I do to try
and block this mail. All the mail still goes through to the internal
gateway.
I'd like to cut this mail off at the external gateway. The external
gateway runs MIMEDefang
and I could use that, but I thought there might be a native sendmail way
to do it.
Scott Field
Andrzej Filip
You can use non local virtusertable available since sendmail 8.10.
It will allow you to use virtusertable entries like:
no-long...@the.domain error:nouser Address no longer valid
--
Andrzej (Andrew) A. Filip an...@bigfoot.com http://www.polbox.com/a/anfi
366A 5DD7 7707 379C 9251 32AE C948 0BD2 7D99 688A expires: 2003-01-25
I may disagree with the following random epigram:
To many, total abstinence is easier than perfect moderation.
-- St. Augustine
Scott Field
The answer turned out to be adding the users to access database on the
external machine,
to send an error for these users.
My previous testing must have been in error because I thought I tried this
before, but anyway
it worked this time.
What's the difference between the access database, which can already block
users, and using the blacklist_recipients
feature as well?
www.sendmail.org does not seem to point out what exactly this feature does
that the normal access database cannot.
Scott.
Andrzej Filip
there is more than one way to do things right :-)
[ perl motto ]
virtusertable based blocking can block even messages not submitted by smtp
[ e.g. in pre 8.12 locally submitted messages or messages received via UUCP ]
Scott Field wrote:
> Thanks to all who replied.
>
> The answer turned out to be adding the users to access database on the
> external machine,
> to send an error for these users.
>
> My previous testing must have been in error because I thought I tried this
> before, but anyway
> it worked this time.
>
> What's the difference between the access database, which can already block
> users, and using the blacklist_recipients
> feature as well?
> www.sendmail.org does not seem to point out what exactly this feature does
> that the normal access database cannot.
>
> Scott.
> [...]
--
Andrzej (Andrew) A. Filip an...@bigfoot.com http://www.polbox.com/a/anfi
366A 5DD7 7707 379C 9251 32AE C948 0BD2 7D99 688A expires: 2003-01-25
I may disagree with the following random epigram:
Democracy is a process by which the people are free to choose the man who
will get the blame.
-- Laurence J. Peter
Per Hedeland
<sfi...@idx.com.au> writes:
>What's the difference between the access database, which can already block
>users, and using the blacklist_recipients
>feature as well?
cf/README seems clear:
blacklist_recipients
Turns on the ability to block incoming mail for certain
recipient usernames, hostnames, or addresses. For
example, you can block incoming mail to user nobody,
host foo.mydomain.com, or gu...@bar.mydomain.com.
These specifications are put in the access db as
described in the anti-spam configuration control section
later in this document.
I.e., blacklist_recipients turns on the ability to block recipients via
access db - they're not alternatives.
--Per Hedeland
p...@bluetail.com
Scott Field
It is clear, as a stand alone statement.
On a more careful reading of http://www.sendmail.org/m4/cf-readme.txt,
I see that that you can put email addresses in access.db and they will be
acted upon,
but blacklist_recipients adds the ability to put *local* addresses in
access.db.
Scott.
Per Hedeland
<sfi...@idx.com.au> writes:
>
>On a more careful reading of http://www.sendmail.org/m4/cf-readme.txt,
>I see that that you can put email addresses in access.db and they will be
>acted upon,
>but blacklist_recipients adds the ability to put *local* addresses in
>access.db.
I can see how you could get that impression, but it's wrong. Recipient
addresses are simply not looked up in access db *at all* unless you use
blacklist_recipients, and if you use it, *both* local and non-local
addresses are looked up (though entries of the form user@ are only ever
matched if the domain-part of the address is local, for rather obvious
reasons).
I guess maybe the part saying
If you use:
FEATURE(`blacklist_recipients')
then you can add entries to the map for local users, hosts in your
domains, or addresses in your domain which should not receive mail:
gave you the incorrect impression, but (except for the "local users"
part as noted above) that is basically just stating what the purpose of
this feature is (generally you're not interested in blocking mail to
remote recipients) - and the section also later on has an example of
non-local addresses:
Enabling this feature
will keep you from sending mails to all addresses that have an
error message or REJECT as value part in the access map. Taking
the example from above:
spa...@aol.com REJECT
cyberspammer.com REJECT
Mail can't be sent to spa...@aol.com or anyone at cyberspammer.com.
And here's a test to prove it all (try it yourself:-) -
With no blacklist_recipients in the .mc file:
sendmail -bt
> /map access sfi...@idx.com.au
map_lookup: access (sfi...@idx.com.au) returns REJECT (0)
sendmail -bs
...
rcpt to: <sfi...@idx.com.au>
250 2.1.5 <sfi...@idx.com.au>... Recipient ok
After adding blacklist_recipients and rebuilding sendmail.cf (no other
changes):
rcpt to: <sfi...@idx.com.au>
550 5.2.1 <sfi...@idx.com.au>... Mailbox disabled for this recipient
--Per Hedeland
p...@bluetail.com
Scott Field
Per Hedeland wrote:
> In article <3C8C8EF9...@idx.com.au> Scott Field
> <sfi...@idx.com.au> writes:
> >
> >On a more careful reading of http://www.sendmail.org/m4/cf-readme.txt,
> >I see that that you can put email addresses in access.db and they will be
> >acted upon,
> >but blacklist_recipients adds the ability to put *local* addresses in
> >access.db.
>
> I can see how you could get that impression, but it's wrong. Recipient
> addresses are simply not looked up in access db *at all* unless you use
> blacklist_recipients, and if you use it, *both* local and non-local
> addresses are looked up (though entries of the form user@ are only ever
> matched if the domain-part of the address is local, for rather obvious
> reasons).
>
> I guess maybe the part saying
>
> If you use:
>
> FEATURE(`blacklist_recipients')
>
> then you can add entries to the map for local users, hosts in your
> domains, or addresses in your domain which should not receive mail:
>
> gave you the incorrect impression,
Thats right, also because the explanation of the access database and what
to put in it (which is before the blacklist_recipients explanation),
does not mention blacklist_recipients. So I thought (wrongly) that
access just stood alone. Somehow these two things don't look related
in the cf/README.
> but (except for the "local users"
> part as noted above) that is basically just stating what the purpose of
> this feature is (generally you're not interested in blocking mail to
> remote recipients) -
Yes, now that you come to say that, of course!
> and the section also later on has an example of
> non-local addresses:
>
> Enabling this feature
> will keep you from sending mails to all addresses that have an
> error message or REJECT as value part in the access map. Taking
> the example from above:
>
> spa...@aol.com REJECT
> cyberspammer.com REJECT
>
> Mail can't be sent to spa...@aol.com or anyone at cyberspammer.com.
>
> And here's a test to prove it all (try it yourself:-) -
>
> With no blacklist_recipients in the .mc file:
>
> sendmail -bt
> > /map access sfi...@idx.com.au
> map_lookup: access (sfi...@idx.com.au) returns REJECT (0)
>
Thanks for this tip, I will have a play around with access this way.
>
> sendmail -bs
> ...
> rcpt to: <sfi...@idx.com.au>
> 250 2.1.5 <sfi...@idx.com.au>... Recipient ok
>
> After adding blacklist_recipients and rebuilding sendmail.cf (no other
> changes):
>
> rcpt to: <sfi...@idx.com.au>
> 550 5.2.1 <sfi...@idx.com.au>... Mailbox disabled for this recipient
>
>
Thanks for the help
Scott.
>
> --Per Hedeland
> p...@bluetail.com
Per Hedeland
<sfi...@idx.com.au> writes:
>
>Thats right, also because the explanation of the access database and what
>to put in it (which is before the blacklist_recipients explanation),
>does not mention blacklist_recipients. So I thought (wrongly) that
>access just stood alone. Somehow these two things don't look related
>in the cf/README.
Well, access db does "stand alone", and that preceding section describes
that basic functionality, which concerns blocking various "sources"
(connecting hosts, e-mail sender addresses) and controlling relaying.
The blacklist_recipients feature uses access db for additional
functionality, blocking e-mail recipient addresses - access db can also
be used for many other things, described in various places in cf/README,
e.g. STARTTLS-related parameters and (in 8.12) client-side AUTH and
queue groups.
--Per Hedeland
p...@bluetail.com
Scott Field
Per Hedeland wrote:
> In article <3C8DF238...@idx.com.au> Scott Field
> <sfi...@idx.com.au> writes:
> >
> >Thats right, also because the explanation of the access database and what
> >to put in it (which is before the blacklist_recipients explanation),
> >does not mention blacklist_recipients. So I thought (wrongly) that
> >access just stood alone. Somehow these two things don't look related
> >in the cf/README.
>
> Well, access db does "stand alone", and that preceding section describes
> that basic functionality, which concerns blocking various "sources"
> (connecting hosts, e-mail sender addresses) and controlling relaying.
>
At my company, on the external sendmail server I currently relay
mycompany.com.au.
What I would like to do is relay mycompany.com.au from outside to inside, but
only
from the internal sendmail hub " internal.mycompany.com.au" when going in to
out.
But I can't see how to achieve this in access.
I thought relay_hosts_only might help, then I could specify a host, but then
how would
I specify a domain?
The other minor problem I have is that sometimes people at our company
mistakenly leave
off ".au" on the email domain when sending mail. The mail then ends up at
"mycompany.com"
instead of here at our mycompany.com.au.
So, I rejected "mycompany.com" in the access database. Unfortunately this also
blocks
mycompany.com from sending stuff to us, like any more problems. I would like
to be able
to receive mail from mycompany.com.
Finally, in cf/README, I could not understand the comment in the anti-spam
config control section
that said:
If you also use
FEATURE('relay_hosts_only')
then the above example will allow relaying for sendmail.org, but *not* hosts
within the
sendmail.org domain.
The explanation is sort of opposite to the feature's wording, or is it just
me.
> The blacklist_recipients feature uses access db for additional
> functionality, blocking e-mail recipient addresses - access db can also
> be used for many other things, described in various places in cf/README,
> e.g. STARTTLS-related parameters and (in 8.12) client-side AUTH and
> queue groups.
>
Yes I see now.
Scott.
>
> --Per Hedeland
> p...@bluetail.com
Per Hedeland
<sfi...@idx.com.au> writes:
>
>At my company, on the external sendmail server I currently relay
>mycompany.com.au.
>
>What I would like to do is relay mycompany.com.au from outside to inside, but
>only
>from the internal sendmail hub " internal.mycompany.com.au" when going in to
>out.
>But I can't see how to achieve this in access.
Put a bit differently, you want to allow relaying when the connecting
host is internal.mycompany.com.au, but you don't want to allow relaying
from anywhere to us...@internal.mycompany.com.au, right? If so, use this
in access
Connect:internal.mycompany.com.a RELAY
Assumes sendmail 8.10.0 or greater.
>I thought relay_hosts_only might help, then I could specify a host, but then
>how would
>I specify a domain?
The difference between a domain and a host can sometimes be confusing -
basically, in e-mail (and DNS!) context, there isn't one. By default, an
LHS of 'foo.bar' in the access db matches both the exact string and
<anything>.foo.bar - relay_hosts_only removes the latter, i.e. an exact
match is required. Perhaps it should have been relay_domains_only:-) -
but that would probably have confused more people, since "allow relaying
for a domain" would typically be taken to mean "allow relaying for all
hosts in the domain".
>The other minor problem I have is that sometimes people at our company
>mistakenly leave
>off ".au" on the email domain when sending mail. The mail then ends up at
>"mycompany.com"
>instead of here at our mycompany.com.au.
>
>So, I rejected "mycompany.com" in the access database. Unfortunately this also
>blocks
>mycompany.com from sending stuff to us, like any more problems. I would like
>to be able
>to receive mail from mycompany.com.
You can use
To:mycompany.com REJECT
for that. However it doesn't seem like a good plan if users can receive
mail from there but not reply to it. I'd suggest you give it up and let
your users learn by trial and error if they are unable to do it in some
more sophisticated way. MUAs with built-in "address book" may also help.
Or change your domain name.:-)
>Finally, in cf/README, I could not understand the comment in the anti-spam
>config control section
>that said:
>If you also use
>FEATURE('relay_hosts_only')
>then the above example will allow relaying for sendmail.org, but *not* hosts
>within the
>sendmail.org domain.
>
>The explanation is sort of opposite to the feature's wording, or is it just
>me.
See above.
--Per Hedeland
p...@bluetail.com
Scott Field
Per Hedeland wrote:
> In article <3C927820...@idx.com.au> Scott Field
> <sfi...@idx.com.au> writes:
> >
> >At my company, on the external sendmail server I currently relay
> >mycompany.com.au.
> >
> >What I would like to do is relay mycompany.com.au from outside to inside, but
> >only
> >from the internal sendmail hub " internal.mycompany.com.au" when going in to
> >out.
> >But I can't see how to achieve this in access.
>
> Put a bit differently, you want to allow relaying when the connecting
> host is internal.mycompany.com.au,
Yes, I want to let the internal hub relay through the external hub to any address
on the internet.
> but you don't want to allow relaying
> from anywhere to us...@internal.mycompany.com.au, right?
For outbound mail, I want to
1. allow the internal hub to relay mail through the external hub to the internet
2. block all other internal clients from relaying through the external hub to the
internet.
For inbound mail, I want to let anyone on the internet send to mycompany.com.au
and have the mail relayed to the internal hub.
My problem is that
1. If I tell access on the external hub to relay only for the internal hub
machine,
then all incoming mail for mycompany.com.au from the internet is blocked with
"relaying denied"
2. But if I open up access on the external hub to relay for mycompany.com.au
(instead of just
(internal.mycompany.com.au), then all internal clients can get out (relay) through
the external hub.
At the moment, I do relay mycompany.com.au on the external hub. It works fine, it
just
also lets anyone on the internal network relay directly through the external hub,
and I
would like to avoid that.
I want to restrict access to the external hub to the internal hub and anyone on the
internet.
Maybe I could just use a firewall rule on the external hub......
> If so, use this
> in access
>
> Connect:internal.mycompany.com.a RELAY
Thanks for the tip, havent seen connect yet.
>
> Assumes sendmail 8.10.0 or greater.
>
> >I thought relay_hosts_only might help, then I could specify a host, but then
> >how would
> >I specify a domain?
>
> The difference between a domain and a host can sometimes be confusing -
> basically, in e-mail (and DNS!) context, there isn't one.
Well that answers a long standing question I've had in the back of my mind.
I always thought it was a slightly vague distinction.
> By default, an
> LHS of 'foo.bar' in the access db matches both the exact string and
> <anything>.foo.bar -
Mmm, OTOH in mailertable isn't it necessary to specify ".foo.bar" rather than
"foo.bar" to
specify <anything>.foo.bar?
> relay_hosts_only removes the latter, i.e. an exact
> match is required. Perhaps it should have been relay_domains_only:-) -
> but that would probably have confused more people, since "allow relaying
> for a domain" would typically be taken to mean "allow relaying for all
> hosts in the domain".
Thanks, thats cleared up my confusion there.
>
>
> >The other minor problem I have is that sometimes people at our company
> >mistakenly leave
> >off ".au" on the email domain when sending mail. The mail then ends up at
> >"mycompany.com"
> >instead of here at our mycompany.com.au.
> >
> >So, I rejected "mycompany.com" in the access database. Unfortunately this also
> >blocks
> >mycompany.com from sending stuff to us, like any more problems. I would like
> >to be able
> >to receive mail from mycompany.com.
>
> You can use
>
> To:mycompany.com REJECT
>
> for that. However it doesn't seem like a good plan if users can receive
> mail from there but not reply to it.
Thats OK because "mycompany.com" only ever sends stuff to postmaster
ay mycompany.com.au (me), if we ever send mail to them accidentally. But then
of course I have to reply to their email so yes that is a problem. Oh well.
> I'd suggest you give it up and let
> your users learn by trial and error if they are unable to do it in some
> more sophisticated way.
I think I might give up on that one at this point!
> MUAs with built-in "address book" may also help.
> Or change your domain name.:-)
>
> >Finally, in cf/README, I could not understand the comment in the anti-spam
> >config control section
> >that said:
> >If you also use
> >FEATURE('relay_hosts_only')
> >then the above example will allow relaying for sendmail.org, but *not* hosts
> >within the
> >sendmail.org domain.
> >
> >The explanation is sort of opposite to the feature's wording, or is it just
> >me.
>
> See above.
>
Many thanks for your help, it is much appreciated!
Scott.
>
> --Per Hedeland
> p...@bluetail.com
Per Hedeland
<sfi...@idx.com.au> writes:
>
>For outbound mail, I want to
>1. allow the internal hub to relay mail through the external hub to the internet
The 'Connect:internal.mycompany.com.a RELAY' will do that.
>2. block all other internal clients from relaying through the external
>hub to the
>internet.
That's the default...
>For inbound mail, I want to let anyone on the internet send to mycompany.com.au
>and have the mail relayed to the internal hub.
>
>My problem is that
>1. If I tell access on the external hub to relay only for the internal hub
>machine,
>then all incoming mail for mycompany.com.au from the internet is blocked with
>"relaying denied"
>
>2. But if I open up access on the external hub to relay for mycompany.com.au
>(instead of just
>(internal.mycompany.com.au), then all internal clients can get out
>(relay) through
>the external hub.
So use
To:mycompany.com.au RELAY
- it won't let the internal clients relay.
>Thanks for the tip, havent seen connect yet.
All the tags are described in cf/README.
>Mmm, OTOH in mailertable isn't it necessary to specify ".foo.bar" rather than
>"foo.bar" to
>specify <anything>.foo.bar?
Yes. I.e. mailertable and access work differently in this respect,
probably because it makes the most sense in the respective case.
--Per Hedeland
p...@bluetail.com
Scott Field
Per Hedeland wrote:
Per, I just tried these two access rules out and it looks like they are working.
What I like is how the defaults cut in and give you what you want if you
use them properly. Eg on the external machine, as you pointed out, all
other internal clients are blocked by default and you just open it up for
the one internal machine you want to let through.
While I was testing it I gave myself a nasty fright forgetting that if
you send mail from root (another good reason not to work as root!) the
sender address does not get masqueraded (EXPOSED_USER spike pit)
and so my mail to outside was getting rejected because it still had the internal
machines name on it. Ahh, my blood pressure levels were too low anyway...
Thanks once again for your help
Scott.