Re: Fixing open relay problem

2019-01-22 Thread Viktor Dukhovni
On Mon, Jan 21, 2019 at 10:21:07PM -0800, Stephen McHenry wrote:

> The two config parameters that seem most relevant to the problem are listed
> below:
> (from postconf -n)
> 
> smtpd_recipient_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   permit_auth_destination,

Though it does not explain the purported open relay issue,
"permit_auth_destination" here makes no sense.  I think you should
delete it.  Anything it does not permit is sure to be blocked below,
so it is simpler to just move "reject_unauth_destination" here
(multiple back-to-back conditional rejects "commute" and a conditional
permit followed by the opposite reject is equivalent to that permit
followed by an unconditional "reject").  So this is effectively your
last rule.

>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_unauth_destination,

With the "permit_auth_destination" above, nothing ever gets past
this point.  So all the rules below are then pointless.

>   reject_unlisted_recipient,
>   reject_unauth_destination,
>   check_recipient_access regexp:/etc/postfix/recipient_checks.regexp,
>   check_recipient_access hash:/etc/postfix/recipient_checks,
>   reject_unauth_pipelining,
>   reject_invalid_hostname,
>   reject_non_fqdn_hostname,
>   reject_rbl_client domain-name,
>   permit

> (and from postconf -d)
> 
> smtpd_relay_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   defer_unauth_destination

I charitably assume you're posting "postconf -d" because you don't
specify this at all in main.cf.  It is best to not let the default
stand in this case, and to replace "defer_unauth_destination" with
"reject_unauth_destination".

With that default in place, relaying can only happen:

1.  From clients in "mynetworks"
2.  From SASL authenticated accounts
3.  To domains listed in mydestination, relay_domains,
virtual_mailbox_domains, virtual_alias_domains.

So if mail from 3rd parties is being routed to 3rd parties, one of
these three is the problem.  The 3rd can be an issue if something
in your system is resending mail based on "To/Cc" headers, rather
than the message envelope.  Check for misconfigured message processing
code.

Finally, make sure that the "open relay" messages are actually coming
in via SMTP.  There's always web forms, and the like.

> What's really confounding me is that it seems to be (properly) rejecting
> all relay email except those that have mydomain.com in their from address.
> Adding to that confusion is that this same set of config parameters used to
> work fine on the old system, so I've also been looking at relevant defaults
> that changed. Unfortunately, I'm coming up dry at this point.
> 
> Any help or pointers would be greatly appreciated.

1.  You should check master.cf, and especially its "submission" entry
for any poorly configured rules.

2.  You should post the *full* output of "postconf -nf" with
no reformatting of the output even to change line breaks.

3.  You should post logs that show Postfix accepting and
delivering an instance of unauthorized relaying.

4.  Make sure you don't have any compromised SASL accounts

5.  Make sure that "mynetworks" is not misconfigured.

6.  Make sure that master.cf overrides (postconf -Mf?) are
not breaking relay control for either port 25, or submission,
...

-- 
Viktor.


Re: Fixing open relay problem

2019-01-22 Thread Larry Stone
On Jan 22, 2019, at 1:30 AM, Dominic Raferd  wrote:
> 
> On Tue, 22 Jan 2019 at 06:22, Stephen McHenry  
> wrote:
>> (and from postconf -d)
>> smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
>> defer_unauth_destination
>> 
>> 
> I think you are just lucky that this didn't happen till now. Note that 
> postconf -d just shows the defaults, not what you are using.
> 

Yes. Please shows us the postconf -n value of smtpd_relay_restrictions

> My approach (a typical one I think) is to block all emails with envelope 
> sender @mydomain.com unless the client has authenticated via port 465 or 587:

Not so typical IMHO. And probably unneeded to solve the OP’s problem. Once we 
see what he really had in smtp_relay_restrictions, we are likely to find a 
simple issue there that he can easily fix.

-- 
Larry Stone
lston...@stonejongleux.com





Re: Postfix logging without syslogd

2019-01-22 Thread Wietse Venema
Viktor Dukhovni:
> On Mon, Jan 21, 2019 at 07:04:56PM -0500, Wietse Venema wrote:
> 
> > postfix-3.4-20190121-nonprod-logger has lightly-tested code for
> > logging to file without using syslogd. 
> 
> I see that the postlogd(8) service correctly uses a unix-dgram
> service to avoid message reordering, so the usual attention to
> detail has not deserted you. :-)  Thanks!

A lot of attention to detail went into this, but I have no control
over how the kernel's unix-domain datagram implementation buffers
messages until the postlogd service is ready. That's why messages
are time-stamped by the sender, not receiver.

> For log rotation instructions, I would add that the old file should
> not be modified, compressed or otherwise assumed complete, until a
> new file is observed to have been written by postlogd(8) after
> processing the "reload" command.  If one is not sure whether Postfix
> is running, one could use postlog(1) (as root) to cause a new file
> to be written, one way or the other.

The Postfix master immediately signals postlogd to terminate. This
being a single-instance event-driven service, it should terminate
immediately unless it is blocked on file writes.

> The only other nit that comes to mind, is that some syslog servers
> needlessly delete and re-create their unix-dgram sockets on reload,
> which leads to needless opportunities for brief loss of messages
> written to the previous incarnation of the socket.

The Postfix master does not close a socket, unless the service is
removed from master.cf, or master_service_disable is in effect.

Wietse