On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 <r...@gmx.co.uk> wrote:
> >
> > Here are my current entries:
> >
> > smtpd_recipient_restrictions =
> > permit_mynetworks,
> > permit_sasl_authenticated,
>
> I don't put these permit_* in global restrictions; I only apply them
> to submission via -o smtpd_relay_restrictions=... in master.cf. And
> that brings up another point: if you're using 2.10 you now have
> smtpd_relay_restrictions for relay control.
>
First, thanks for the extremely insightful help, Rob.
OK - I commented those two lines out of smtpd_recipient_restrictions as
recommended, and added a new smtpd_relay_restrictions -o line to submission
in master.cf. My submission now reads:
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o
smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
However, I get this when sending a message from my home desktop (connected
via Comcast) via my personal Postfix server to my Gmail test address:
May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject_warning:
RCPT from c-xx-xxx-xx-xx.hsd1.wa.comcast.net[xx.xxx.xx.xx]: 504 5.5.2
<STEVEJPC>: Helo command rejected: need fully-qualified hostname; from=<
u...@example.com> to=<u...@gmail.com> proto=ESMTP helo=<STEVEJPC>
May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject_warning:
RCPT fromc-xx-xxx-xx-xx.hsd1.wa.comcast.net[[xx.xxx.xx.xx]: 450 4.7.1
<STEVEJPC>: Helo command rejected: Host not found; from=<u...@example.com>
to=<u...@gmail.com> proto=ESMTP helo=<STEVEJPC>
May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject: RCPT
fromc-xx-xxx-xx-xx.hsd1.wa.comcast.net[[xx.xxx.xx.xx]: 554 5.7.1 <
c-xx-xxx-xx-xx5.hsd1.wa.comcast.net[xx.xxx.xx.xx]>: Unverified Client host
rejected: Generic - Please relay via ISP (comcast.net); from=<
u...@example.com> to=<u...@gmail.com> proto=ESMTP helo=<STEVEJPC>
That last line is a result of using from Stan's excellent PCRE file (using
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre).
Uncommenting the two permit_* lines in smtpd_recipient_restrictions allows
the message to send without error. I'm running 2.10.0 so
smtpd_relay_restrictions should be available to me, but I'm not sure why
it's not working as I expected it to on the submission. I'm also wondering
if I no longer need that -o smtpd_client_restrictrions in master.cf (
>
> > reject_invalid_hostname,
>
> Deprecated syntax for reject_invalid_helo_hostname.
>
> > reject_unauth_destination,
>
> See above re: smtpd_relay_restrictions.
>
> > warn_if_reject reject_non_fqdn_hostname,
>
> I consider this one quite safe. In fact, it's one of the CBL's
> listing criteria; when they see a host using a non-FQDN as HELO, it
> will be listed. Deprecated syntax again.
>
> > warn_if_reject reject_non_fqdn_sender,
> > reject_non_fqdn_recipient,
> > reject_unknown_sender_domain,
>
> These are safe, but mostly pointless here. You might want them on
> submission, in case a user has a misconfigured MUA.
>
> > warn_if_reject reject_unknown_reverse_client_hostname,
>
> Safe, because many large receivers do this as well.
>
> > warn_if_reject reject_non_fqdn_helo_hostname,
>
> This is the new syntax for reject_non_fqdn_hostname, you do the
> warning twice for the same thing.
>
> > warn_if_reject reject_invalid_helo_hostname,
>
> Deja vu all over again!
>
> > warn_if_reject reject_unknown_helo_hostname,
>
> This one is NOT safe. A lot of sites use HELOs which don't resolve.
> So I'd not take off the warn_if_reject.
>
> > reject_unauth_pipelining,
>
> This could go higher. It's a "cheap" restriction.
>
> > check_reverse_client_hostname_access
> pcre:/etc/postfix/fqrdns.pcre,
> > check_helo_access hash:/etc/postfix/helo_access,
> > check_sender_access hash:/etc/postfix/check_backscatterer,
> > check_sender_access hash:/etc/postfix/access,
>
> "access" is not a descriptive name. I would name it either
> "sender_access" or whatever the general purpose of the lookup is. It
> could also be merged with the check_backscatterer lookup.
>
> > reject_rhsbl_client dbl.spamhaus.org,
> > reject_rhsbl_sender dbl.spamhaus.org,
> > reject_rhsbl_helo dbl.spamhaus.org,
> > permit
> >
> > My guess would be to either put them just after the
> > reject_unknown_sender_domain or just before the
> > check_reverse_client_hostname... but that's a total guess.
> > The BRBL entry I'd stick back just in front of the
> > reject_rhsbl_client entry.
>
> I wouldn't whitelist the check_*_access lookups, but you might choose
> to do that for your own reasons.
>
> I would put Zen just before the three DBL lookups. This way the DBL
> lookups might be avoided. I'd keep DBL before DNSWL. I doubt the
> DNSWL folks want to list any client sending for DBL-listed domains,
> so check DBL first.
>
> The "low, medium, and high" idea is good, although recently I have
> seen a case where BRBL listed a DNSWL "none" host (with legitimate
> mail, sigh.)
Based on all of the above excellent recommendations, my
smtpd_*_restrictions in main.cf now read:
# SMTPD Restrictions
smtpd_helo_required = yes
disable_vrfy_command = yes
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_pipelining,
reject_invalid_helo_hostname,
warn_if_reject reject_non_fqdn_helo_hostname,
reject_unknown_reverse_client_hostname,
warn_if_reject reject_unknown_helo_hostname,
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
check_helo_access hash:/etc/postfix/helo_access,
check_sender_access hash:/etc/postfix/sender_access,
reject_rbl_client zen.spamhaus.org,
reject_rhsbl_client dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org,
permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
permit
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
Much cleaner, thanks (plz let me know if I'm still obtusely
misunderstanding anything in there).
However, I'm still scratching me head as to why the
smtpd_relay_restrictions on submission aren't allowing my SASL
authenticated message to sail through.
Thanks in advance to anyone who can help troubleshoot,
SteveJ
