check_recipient_access not working as expected

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

check_recipient_access not working as expected

Charles Marcus
Ok, I'm trying to implement this as described by Brian Evans, but I must
be missing something...

I have created the 'moved' file, with contents (the only single entry is
all on one line):

# users no longer with Our Company
[hidden email]  REJECT  Firstname is no longer employed with Our Company

I then postmapped the file and added the check_recipient_access to my
recipient restrictions (snipped postconf -n output):

smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,  reject_unauth_destination,
check_client_access cidr:/etc/postfix/allowed_clients.cidr,
check_recipient_access hash:/etc/postfix/moved,  reject

After a postfix reload, I sent a test message from one of my external
accounts, and the message is delivered, instead of REJECTED, as I expected:

Jun  7 10:59:57 myhost postfix/smtpd[27735]: connect from
ixe-mta-18-tx.emailfiltering.com[194.116.198.213]
Jun  7 10:59:58 myhost postfix/smtpd[27735]: setting up TLS connection
from ixe-mta-18-tx.emailfiltering.com[194.116.198.213]
Jun  7 10:59:58 myhost postfix/smtpd[27735]: Anonymous TLS connection
established from ixe-mta-18-tx.emailfiltering.com[194.116.198.213]:
TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Jun  7 10:59:58 myhost postfix/smtpd[27735]: 990F9FF529:
client=ixe-mta-18-tx.emailfiltering.com[194.116.198.213]
Jun  7 10:59:58 myhost postfix/cleanup[27741]: 990F9FF529:
message-id=<[hidden email]>
Jun  7 10:59:58 myhost postfix/qmgr[27646]: 990F9FF529:
from=<[hidden email]>, size=1257, nrcpt=1 (queue active)
Jun  7 10:59:59 myhost postfix/virtual[27743]: 990F9FF529:
to=<[hidden email]>, relay=virtual, delay=0.48,
delays=0.47/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
Jun  7 10:59:59 myhost postfix/qmgr[27646]: 990F9FF529: removed

Why is it not REJECTed?

Full (anonymized) postconf -n output follows:

myhost ~ # postconf -n
alias_database = hash:/etc/mail/aliases
alias_maps = hash:/etc/mail/aliases, hash:/var/lib/mailman/data/aliases
anvil_rate_time_unit = 360s
anvil_status_update_time = 3600s
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib64/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 20
delay_warning_time = 2h
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.5.1/html
local_destination_concurrency_limit = 2
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 51200000
mydomain = example.com
myhostname = smtp.example.com
mynetworks = 127.0.0.1
newaliases_path = /usr/bin/newaliases
owner_request_special = no
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.5.1/readme
recipient_delimiter = +
relayhost = [smtp.ourisp.net]
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions =
smtpd_hard_error_limit = 3
smtpd_helo_restrictions =
smtpd_recipient_limit = 100
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,  reject_unauth_destination,
check_client_access cidr:/etc/postfix/allowed_clients.cidr,
check_recipient_access hash:/etc/postfix/moved,  reject
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions =
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/wildcard.crt
smtpd_tls_key_file = /etc/ssl/wildcard.key
smtpd_tls_loglevel = 1
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf,
hash:/var/lib/mailman/data/virtual-mailman
virtual_gid_maps = static:207
virtual_mailbox_base = /var/virtual
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domain_maps.cf
virtual_mailbox_limit = 51200000
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 207
virtual_transport = virtual
virtual_uid_maps = static:207
myhost ~ #

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

Victor Duchovni
On Sat, Jun 07, 2008 at 11:16:12AM -0400, Charles Marcus wrote:

> I then postmapped the file and added the check_recipient_access to my
> recipient restrictions (snipped postconf -n output):
>
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated,  reject_unauth_destination,
> check_client_access cidr:/etc/postfix/allowed_clients.cidr,
> check_recipient_access hash:/etc/postfix/moved,  reject

Not much point putting selective "REJECT" rules just before a blanket
"reject". The mail would be rejected equally well by the final "reject",
were it not for earlier rules (anyone want to bet on allowed_clients.cidr?)
that permit it.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

/dev/rob0
In reply to this post by Charles Marcus
On Sat June 7 2008 10:16:12 Charles Marcus wrote:

> Ok, I'm trying to implement this as described by Brian Evans, but I
> must be missing something...
>
> I have created the 'moved' file, with contents (the only single entry
> is all on one line):
>
> # users no longer with Our Company
> [hidden email]  REJECT  Firstname is no longer employed with Our
> Company
>
> I then postmapped the file and added the check_recipient_access to my
> recipient restrictions (snipped postconf -n output):
>
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated,  reject_unauth_destination,
> check_client_access cidr:/etc/postfix/allowed_clients.cidr,
> check_recipient_access hash:/etc/postfix/moved,  reject
>
> After a postfix reload, I sent a test message from one of my
> external accounts,

And is this external account's outMX in your allowed_clients.cidr map?

> and the message is delivered, instead of REJECTED, as I
> expected:
snip
> Why is it not REJECTed?

Inadequate information without the allowed_clients.cidr map, but why
don't you just put the check_recipient_access first? Don't you want
internal users to be rejected too?
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

/dev/rob0
In reply to this post by Victor Duchovni
On Sat June 7 2008 10:26:09 Victor Duchovni wrote:

> On Sat, Jun 07, 2008 at 11:16:12AM -0400, Charles Marcus wrote:
> > I then postmapped the file and added the check_recipient_access to
> > my recipient restrictions (snipped postconf -n output):
> >
> > smtpd_recipient_restrictions = permit_mynetworks,
> > permit_sasl_authenticated,  reject_unauth_destination,
> > check_client_access cidr:/etc/postfix/allowed_clients.cidr,
> > check_recipient_access hash:/etc/postfix/moved,  reject
>
> Not much point putting selective "REJECT" rules just before a blanket
> "reject". The mail would be rejected equally well by the final
> "reject", were it not for earlier rules (anyone want to bet on
> allowed_clients.cidr?) that permit it.

Oh, now I remember, this poster uses Postini, so it definitely did
arrive from an allowed_clients.cidr host. That also explains the final
"reject" restriction.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

Charles Marcus
In reply to this post by /dev/rob0
On 6/7/2008 11:29 AM, /dev/rob0 wrote:
> And is this external account's outMX in your allowed_clients.cidr map?

No... but you did provide the reason why it is being delivered below -
and generated one last question (again, below)...

>> and the message is delivered, instead of REJECTED, as I
>> expected:
> snip
>> Why is it not REJECTed?
>
> Inadequate information without the allowed_clients.cidr map,

 >> Not much point putting selective "REJECT" rules just before a blanket
 >> "reject". The mail would be rejected equally well by the final
 >> "reject", were it not for earlier rules (anyone want to bet on
 >> allowed_clients.cidr?) that permit it.

 > Oh, now I remember, this poster uses Postini,

Actually, its webroot, but yeah, same thing...

allowed_clients.cidr
# allow webmail
127.0.0.1          permit

# valid webroot IP blocks
###.###.###.###/28   permit
###.###.###.###/26   permit
###.###.###.###/23   permit

> but why don't you just put the check_recipient_access first? Don't
> you want internal users to be rejected too?

Not important - everyone here knows who is and is not still working here...

I thought that checks after check_client_access would still be used...
but now I see (by simply looking at the contents of allowed_clients)
that the permit action above would skip further checks, thanks...

I try to set up checks so as to be least expensive, and I thought
checking recipient access on a client that would not be allowed would be
more expensive...

But if simply moving it up will fix it without adding significant load
on postfix, that would be ok too... but...

Isn't there a way to make the allowed clients work in reverse?

Ie, tell it to block anything that doesn't fit one of the netblocks, and
give a DUNNO for the rest, to allow the next checks to work?

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

/dev/rob0
On Sat June 7 2008 11:06:42 Charles Marcus wrote:
>  > Oh, now I remember, this poster uses Postini,
>
> Actually, its webroot, but yeah, same thing...

Also, it means you're going about this all wrong. You should not use
check_recipient_access in a case like this. You should go to your MX
provider and change their recipient maps. If this is not possible, ask
yourself if this is a service worth paying for.

The issue: spammers hit [hidden email], the MX accepts it, you
reject it, and the MX sends backscatter.

(If the MX is using a variation of recipient verification as described
in the Postfix ADDRESS_VERIFICATION_README.html, your method will work,
but the MX might need to flush their verified address cache.)

> I try to set up checks so as to be least expensive, and I thought
> checking recipient access on a client that would not be allowed would
> be more expensive...

A hash: lookup is trivial. No significant difference.

> Isn't there a way to make the allowed clients work in reverse?
>
> Ie, tell it to block anything that doesn't fit one of the netblocks,
> and give a DUNNO for the rest, to allow the next checks to work?

Um, sure, use a "DUNNO" target in your client map. But I don't see how
that accomplishes anything useful.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

Victor Duchovni
On Sat, Jun 07, 2008 at 12:10:54PM -0500, /dev/rob0 wrote:

> On Sat June 7 2008 11:06:42 Charles Marcus wrote:
> >  > Oh, now I remember, this poster uses Postini,
> >
> > Actually, its webroot, but yeah, same thing...
>
> Also, it means you're going about this all wrong. You should not use
> check_recipient_access in a case like this. You should go to your MX
> provider and change their recipient maps. If this is not possible, ask
> yourself if this is a service worth paying for.
>
> The issue: spammers hit [hidden email], the MX accepts it, you
> reject it, and the MX sends backscatter.

Postini is not a store-and-forward MX provider. They proxy the traffic.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

Charles Marcus
In reply to this post by /dev/rob0
/dev/rob0 wrote:
>> Actually, its webroot, but yeah, same thing...

> Also, it means you're going about this all wrong. You should not use
> check_recipient_access in a case like this. You should go to your MX
> provider and change their recipient maps. If this is not possible, ask
> yourself if this is a service worth paying for.

No, you don't understand...

They PROXY the connection to check my servers response for a valid
recipient. If my server rejects it, THEY reject it...

> (If the MX is using a variation of recipient verification as described
> in the Postfix ADDRESS_VERIFICATION_README.html, your method will work,
> but the MX might need to flush their verified address cache.)

Again, they query my server in real time. This is not a problem.

>> I try to set up checks so as to be least expensive, and I thought
>> checking recipient access on a client that would not be allowed would
>> be more expensive...

> A hash: lookup is trivial. No significant difference.

Ok, thanks, if I can't get my last question to work, I'll do this.

>> Isn't there a way to make the allowed clients work in reverse?
>>
>> Ie, tell it to block anything that doesn't fit one of the netblocks,
>> and give a DUNNO for the rest, to allow the next checks to work?

> Um, sure, use a "DUNNO" target in your client map. But I don't see how
> that accomplishes anything useful.\

Actually, now that I look more closely, DUNNO wouldn't work... it would
have to be REJECT - see below...

But you also missed the point of my question...

I think there is a way to structure the map so that it works off of a
negative match instead of a positive match - it was something about
using an exclamation point (or some other character) before the pattern
to match on, so, instead of:

# valid webroot IP blocks
###.###.###.###/28   permit
###.###.###.###/26   permit
###.###.###.###/23   permit

it would be something like:

# valid webroot IP blocks
!###.###.###.###/28,!###.###.###.###/26,!###.###.###.###/23 REJECT

This way, the check_client_access could remain before the
check_recipient_access, and still accomplish my goal...

But its sounding like it doesn't really matter?

Best regards,

Charles


Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

mouss-2
Charles Marcus wrote:

> [snip]
> Actually, now that I look more closely, DUNNO wouldn't work... it
> would have to be REJECT - see below...
>
> But you also missed the point of my question...
>
> I think there is a way to structure the map so that it works off of a
> negative match instead of a positive match - it was something about
> using an exclamation point (or some other character) before the
> pattern to match on, so, instead of:
>
> # valid webroot IP blocks
> ###.###.###.###/28   permit
> ###.###.###.###/26   permit
> ###.###.###.###/23   permit
>
> it would be something like:
>
> # valid webroot IP blocks
> !###.###.###.###/28,!###.###.###.###/26,!###.###.###.###/23 REJECT
>
> This way, the check_client_access could remain before the
> check_recipient_access, and still accomplish my goal...
>
> But its sounding like it doesn't really matter?



smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    check_client_access cidr:/etc/postfix/client_access.cidr
    check_recipient_access hash:/etc/postfix/moved

== client_access.cidr:
# valid webroot IP blocks
###.###.###.###/28   dunno
###.###.###.###/26   dunno
###.###.###.###/23   dunno
# other IPs are rejected
0.0.0.0/0                     reject




Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

/dev/rob0
In reply to this post by Charles Marcus
On Sun June 8 2008 11:05:36 Charles Marcus wrote:
> /dev/rob0 wrote:
> >> Actually, its webroot, but yeah, same thing...
> >
> > Also, it means you're going about this all wrong. You should not
> > use check_recipient_access in a case like this. You should go to
> > your MX provider and change their recipient maps. If this is not
> > possible, ask yourself if this is a service worth paying for.
>
> No, you don't understand...

(I did after Viktor explained it.)

> >> Isn't there a way to make the allowed clients work in reverse?
> >>
> >> Ie, tell it to block anything that doesn't fit one of the
> >> netblocks, and give a DUNNO for the rest, to allow the next checks
> >> to work?
> >
> > Um, sure, use a "DUNNO" target in your client map. But I don't see
> > how that accomplishes anything useful.\
>
> Actually, now that I look more closely, DUNNO wouldn't work... it
> would have to be REJECT - see below...
>
> But you also missed the point of my question...
>
> I think there is a way to structure the map so that it works off of a
> negative match instead of a positive match - it was something about
> using an exclamation point (or some other character) before the
> pattern to match on, so, instead of:
>
> # valid webroot IP blocks
> ###.###.###.###/28   permit
> ###.###.###.###/26   permit
> ###.###.###.###/23   permit

It seems odd to me that you'd want to obfuscate those netblocks. No
matter, however.

> it would be something like:
>
> # valid webroot IP blocks
> !###.###.###.###/28,!###.###.###.###/26,!###.###.###.###/23 REJECT
>
> This way, the check_client_access could remain before the
> check_recipient_access, and still accomplish my goal...

The client CIDR map:
        1.2.3.32/28 dunno
        1.2.3.64/26 dunno
        1.2.4.0/23 dunno
        0.0.0.0/0 Reject This server is not MX, go away
Put the check_recipient_access after the check_client_access, and take
out the final "reject" from smtpd_recipient_restrictions. (Oops, while
typing this I see that mouss beat me to it.)

> But its sounding like it doesn't really matter?

Slightly. Doing it the first way (check_recipient_access first) gives
spammers the wrong rejection for former users. Doing it this way, they
get the proper rejection. Not that it matters ...

Anyway, what was the point of this whole thing? ISTM that if you just
remove the user from your recipient maps, you'll give the rejection to
the MX hosts. That would give senders the generic "user unknown in X
table" rejection message. If that's good enough, be done with it.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

Charles Marcus
On 6/8/2008, /dev/rob0 ([hidden email]) wrote:
> Anyway, what was the point of this whole thing? ISTM that if you just
> remove the user from your recipient maps, you'll give the rejection to
> the MX hosts. That would give senders the generic "user unknown in X
> table" rejection message. If that's good enough, be done with it.

Well, of *course* this is true. I don't mean to sound unappreciative - I
do appreciate the help - but you might give me just a *little* credit. ;)

The BOSS told me he wanted a custom REJECT message - either with a new
email address, or not (depending on the person who is leaving the
company). He didn't like the wording provided by the relocated_maps, so
asked me to figure something else out.

I knew it could be done, so it just boiled down to the best
(easiest/cheapest) approach... and now I have it, thanks to you and
mouss and the others who responded...

So, thanks again to all who responded :)

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access not working as expected

/dev/rob0
On Sun June 8 2008 12:28:01 Charles Marcus wrote:
> The BOSS told me he wanted a custom REJECT message - either with a
> new email address, or not (depending on the person who is leaving the
> company). He didn't like the wording provided by the relocated_maps,
> so asked me to figure something else out.

Far be it from me to agree with a PHB, but in this case I do. Ideally
your former users' rejection should not be the same as the rejection
for never-existed users, and likewise, I agree that relocated(5) is a
bit too rigid in wording. A check_recipient_access lookup is, however,
more work for you to maintain. As long as the boss doesn't mind paying
for said work, all is well. :)
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header