Discussion:
Debug smtpd_recipient_restrictions
(too old to reply)
Freek Dijkstra
13 years ago
Permalink
Hi all,

I have set up some new rules in smtpd_recipient_restrictions (see below)
on my test machine. They don't work exactly as I expected. Is there a
way to log the output of each lookup performed? For example, in my
configuration I see some logging from the SPF policy checker, but I have
no clue what the result of the sender_access, client_access or RBLs is.
I can use postmap -q to get some results, but that's a bit cumbersome.

I added a mail.debug rule to syslog, but I don't see any more info than
what is already logged using mail.info.

smtpd_recipient_restrictions = reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
warn_if_reject check_sender_access hash:/etc/postfix/sender_access,
warn_if_reject check_client_access hash:/etc/postfix/client_access,
warn_if_reject check_policy_service unix:private/policy-spf,
warn_if_reject reject_rbl_client relays.ordb.org,
warn_if_reject reject_rbl_client sbl.spamhaus.org,
permit

Second question: I'm currently using check_sender_access to block email
coming from non-existing user addresses at my domain. However, this only
checks the MAIL FROM address. Is it also possible to create a rule which
checks the From: header. (presumably such check should occur in
smtpd_data_restrictions or smtpd_end_of_data_restrictions?)

Regards,
Freek
Freek Dijkstra
13 years ago
Permalink
...
PS: I'm obviously not yet using Postfix 2.10, but only 2.7.1.

Freek
David DeFranco
13 years ago
Permalink
For the first try peer debugging

http://www.postfix.org/DEBUG_README.html#debug_peer

For the second you want a header check.
...
Noel Jones
13 years ago
Permalink
Post by Freek Dijkstra
Hi all,
I have set up some new rules in smtpd_recipient_restrictions (see below)
on my test machine. They don't work exactly as I expected.
If you describe the the unexpected behavior, maybe someone can explain.
Post by Freek Dijkstra
Is there a
way to log the output of each lookup performed?
You can turn on postfix debug mode. Note that debug mode produces
large amounts of logging, and can be hard to decipher since the
important stuff (which is usually present in regular logs) often
gets overlooked in the flood.
http://www.postfix.org/DEBUG_README.html#trace_mail

Use postmap as a low-level debug tool to test lookups. Note that
postmap by design only looks up the key you specify. Most postfix
map features will lookup several variations of the primary key, see
the man page for each feature to see what is searched, such as
http://www.postfix.org/access.5.html
Post by Freek Dijkstra
Second question: I'm currently using check_sender_access to block email
coming from non-existing user addresses at my domain. However, this only
checks the MAIL FROM address. Is it also possible to create a rule which
checks the From: header. (presumably such check should occur in
smtpd_data_restrictions or smtpd_end_of_data_restrictions?)
Not possible. If there are a few frequently-abused From: headers,
you can add those to a header_checks map.




-- Noel Jones
Viktor Dukhovni
13 years ago
Permalink
Post by Freek Dijkstra
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
You generally don't need this one except on port 587, usually after
permit_auth_destination. You should not reject mail to your own
domains just because of a (be it unlikely) transient DNS glitch.

If however a separate submission service is not a good fit, you
can leave it there, as the odds of a problem are relatively low.
Post by Freek Dijkstra
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
Fine, you're not an open relay, provided your mynetworks settings
is sensible and none of your SASL users have weak passwords.
Post by Freek Dijkstra
warn_if_reject check_sender_access hash:/etc/postfix/sender_access,
warn_if_reject check_client_access hash:/etc/postfix/client_access,
warn_if_reject check_policy_service unix:private/policy-spf,
These check the envelope sender address, then the client IP address,
and finally the SPF policy service. Pretty simple really.
Post by Freek Dijkstra
warn_if_reject reject_rbl_client relays.ordb.org,
warn_if_reject reject_rbl_client sbl.spamhaus.org,
IIRC relays.ordb.org is LONG dead, or if not dead, is not a good
choice for most sites.

As for spamhaus, use "zen.spamhaus.org" not "sbl.spamhaus.org".
Post by Freek Dijkstra
Second question: I'm currently using check_sender_access to block email
coming from non-existing user addresses at my domain. However, this only
checks the MAIL FROM address. Is it also possible to create a rule which
checks the From: header. (presumably such check should occur in
smtpd_data_restrictions or smtpd_end_of_data_restrictions?)
No, not without a milter or proxy filter.
--
Viktor.
Benny Pedersen
13 years ago
Permalink
Post by Freek Dijkstra
warn_if_reject reject_rbl_client relays.ordb.org,
old rbl list never dies ?

hint dont add dns check that does not work
Stan Hoeppner
13 years ago
Permalink
Post by Viktor Dukhovni
IIRC relays.ordb.org is LONG dead, or if not dead, is not a good
choice for most sites.
LONG dead is right, for six years now. Offline since Dec 31, 2006:

http://tech.slashdot.org/story/06/12/18/154259/ordborg-going-offline
--
Stan
Freek Dijkstra
13 years ago
Permalink
David and Noel, thanks for the pointer how to trace mails.

Victor -- good catch. I don't remember how I came up with the old
ordb.org. I looked up
https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists and it's not
even listed there.

The following URLs were useful to compare size and effectiveness of
blacklists:
http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html
http://stats.uceprotect.net/?page=cw

In particular the second, since it also contains false positives (and
false negatives?).

I personally don't like greylisting (if only because I don't want to
wait when subscribing to this list, or receiving your useful replies ;))

My ideal configuration would be as follow:
- Check 2 or 3 larger DNS blacklists.
- If it is positive match, greylist. If not, allow the mail right away.
- Add a header with the result of the blacklisting (so spamassassin
can add some points, without doing the lookup again, if it comes
through the greylist the second time)

Is this possible?

Add a greylist is easy with postgrey and something like:

smtpd_restriction_classes = greylist
greylist = check_policy_service inet:127.0.0.1:10023

reject_rbl_client doesn't work, since it rejects the mail instead of
flag it for the above "greylist" class.

I guess I can write a custom script and use check_policy_service.
Would something along these lines already exist?

So far I found http://www.sr71.net/scripts/greylist/, but I rather have
postgrey handle the Greylisting.

(I'm sure it is easy enough to create a policy script, it is just that I
never done it before, and it's always useful to see a working example,
especially when I like to see two actions -- add header and greylist.).

Thanks a lot,
Freek
Noel Jones
13 years ago
Permalink
Post by Freek Dijkstra
- Check 2 or 3 larger DNS blacklists.
- If it is positive match, greylist. If not, allow the mail right away.
- Add a header with the result of the blacklisting (so spamassassin
can add some points, without doing the lookup again, if it comes
through the greylist the second time)
Check the existing policy services at
http://www.postfix.org/addon.html#policy

My first thought would be to use postfwd to check the RBLs, and if
there's a match call the simple but reliable greylist.pl included
with postfix. There are undoubtedly other ways to do this; maybe
one of the existing tools does this all by itself.

Don't bother adding RBL result headers for SpamAssassin; the
previous results will be cached in your DNS and won't add any
significant latency.


-- Noel Jones

Loading...