Re: Mail server recently became an open relay

[IL Ka]

Rock solid solution is to separate htdocs (a folder that is accessible via
web) from the code folder (the one with scripts).
I do not know how that could be done with PHP (I believe you can serve
static files with nginx and run php as FPM connected to the nginx with
FastCGI) but in Python world we have separate process (uwsgi or gunicorn)
that is connected to the nginx and it runs under the different user.
All user files are uploaded to the folder accessible by nginx, far away
from the folder with python scripts.
Even if you upload a .py file, nginx will serve it as a static plain text
file.

On Tue, Oct 20, 2020 at 1:27 AM Demi M. Obenour 
wrote:

> On 10/19/20 3:29 PM, Jaroslaw Rafa wrote:
> > Dnia 19.10.2020 o godz. 21:12:20 John Fawcett pisze:
> >> Sorry not to be able to give a definitive answer. Typical mail injection
> >> via php will use a script that already calls the php mail function or
> >> similar functions that open the smtp connection. But there are other
> >> attack vectors that are possible that allow hackers to gain the
> >> privileges of the web server user.
> >
> > Very often hackers abuse web pages that allow users to upload files to
> the
> > web server. If the input is not correctly sanitized, it may be possible
> to
> > upload an arbitrary php script and get it executed.
> >
> > There were multiple attacks based on this scenario.
>
> Can this be mitigated by denying the PHP user write permission on
> any directory where PHP files will be executed?
>
> Demi
>
>

Re: Mail server recently became an open relay

[Jaroslaw Rafa]

Dnia 19.10.2020 o godz. 18:26:28 Demi M. Obenour pisze:
> Can this be mitigated by denying the PHP user write permission on
> any directory where PHP files will be executed?

There are multiple methods to mitigate this, this may be one of them.

But unsecured scripts that allow such behaviour are still being found here
and there.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Mail server recently became an open relay

[Demi M. Obenour]

On 10/19/20 3:29 PM, Jaroslaw Rafa wrote:
> Dnia 19.10.2020 o godz. 21:12:20 John Fawcett pisze:
>> Sorry not to be able to give a definitive answer. Typical mail injection
>> via php will use a script that already calls the php mail function or
>> similar functions that open the smtp connection. But there are other
>> attack vectors that are possible that allow hackers to gain the
>> privileges of the web server user.
> 
> Very often hackers abuse web pages that allow users to upload files to the
> web server. If the input is not correctly sanitized, it may be possible to
> upload an arbitrary php script and get it executed.
> 
> There were multiple attacks based on this scenario.

Can this be mitigated by denying the PHP user write permission on
any directory where PHP files will be executed?

Demi



OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: Mail server recently became an open relay

[Bob Proulx]

Bob Proulx wrote:
> The default PHP "mail()" method sends mail by using the system's
> /usr/sbin/sendmail interface rather than SMTP.
>
> https://www.php.net/manual/en/mail.requirements.php
> https://www.php.net/manual/en/function.mail.php

Oh!  It depends upon the system's php.ini configuration.  For which
there might be many.  Here is an (older) 7.0 system for example.

/etc$ find php* -name php.ini
php/7.0/cli/php.ini
php/7.0/apache2/php.ini
php/7.0/fpm/php.ini

And the php.ini for both FPM and Apache contains:

[mail function]
; For Win32 only.
; http://php.net/smtp
SMTP = localhost
; http://php.net/smtp-port
smtp_port = 25

My bad for posting my previous misguided information.  Sorry about that.

Bob

Re: Mail server recently became an open relay

[IL Ka]

If someone hacked your PHP script, he or she may add any code to it,
including code that connects to your smtpd and sends email.
In PHP one can use mail() function (which can use TCP connection to the
localhost:25 according to the settings in php.ini) or establish connection
directly.

As we can see from
>Oct 15 14:48:06 memoryalpha postfix/postscreen[18030]: CONNECT from
[127.0.0.1]:52138 to [127.0.0.1]:25

Some locally running process just connected to your server and send spam.
I think you can use iptables to log all connections to this port to catch
the pid of the culprit.

As a quick-and-dirty solution you can move your smtpd to the different port
(see master.cf).
Script would not know about the new port, hence it wouldn't be able to
connect to postfix.

Or you can move smtpd to the unix domain socket or even disable it and
use the "sendmail" interface instead.

Greping your scripts for "socket_connect" and "mail" is also worth doing.

Btw, this is not an "open relay": relaying mail from the localhost
(127.0.0.1) is the default postfix behavior because "mynewtorks =
127.0.0.0/8" in may installations,
and "smtpd_relay_restrictions" includes $mynetworks by default.

If you were running each website in the separate docker instance for
example, then you would be able to create the separate port for each
container in master.cf, and know for sure which one was hacked.





<#m_-2421472136311685306_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Oct 19, 2020 at 9:51 PM Rich Wales  wrote:

> John Fawcett wrote:
>
> > One thing I would suggest looking at is if there is a web server running
> > on the same host it may be allowing email to be injected into postfix
> > via smtp on the loopback interface using some scripting language like
> > php or others.
>
> I suppose that's possible.
>
> I spent some time last night cleaning up old stuff from the server in
> question -- and also rebooting the box for good measure -- so the
> problem *might* just go away at this point.
>
> Before I can say anything more about this, unfortunately, I'll probably
> need to wait for another incident similar to the preceding ones, and try
> to capture more evidence while the problem is ongoing.  If it never
> happens again, then maybe it was the fault of an old PHP web page which
> I have removed.
>
> If the problem were in fact due to a hijacked PHP page, btw, would this
> necessarily require the page to be using e-mail or TCP connections
> already for its own legitimate purposes, but being co-opted by a hacker
> to nefarious ends?  Or could *any* PHP script theoretically be infected
> in a way that would cause this misbehaviour?
>
> Rich Wales
> ri...@richw.org
>


Без
вирусов. www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Mail server recently became an open relay

[Bob Proulx]

Rich Wales wrote:
> If the problem were in fact due to a hijacked PHP page, btw, would this
> necessarily require the page to be using e-mail or TCP connections
> already for its own legitimate purposes, but being co-opted by a hacker
> to nefarious ends?  Or could *any* PHP script theoretically be infected
> in a way that would cause this misbehaviour?

*If* the host is running a site, such as Wordpress but there are also
many other possibilities, and if it is not absolutely up to date with
security upgrades current as of *TODAY*, then it is very likely that
the site has been compromised.

That's just the history of WP and other similar frameworks!  They are
allowed to do brain surgery on themselves without restriction and they
consist of a community of thousands and thousands of inexperienced
developers all submitting modules without a security focus.  When I
read John Fawcett's suggestion that it might be a web server
compromise I thought immediately, "Oh good suggestion!", since that is
so often a typical compromise case!

The default PHP "mail()" method sends mail by using the system's
/usr/sbin/sendmail interface rather than SMTP.

https://www.php.net/manual/en/mail.requirements.php
https://www.php.net/manual/en/function.mail.php

Bob

Re: Mail server recently became an open relay

[Jaroslaw Rafa]

Dnia 19.10.2020 o godz. 21:12:20 John Fawcett pisze:
> Sorry not to be able to give a definitive answer. Typical mail injection
> via php will use a script that already calls the php mail function or
> similar functions that open the smtp connection. But there are other
> attack vectors that are possible that allow hackers to gain the
> privileges of the web server user.

Very often hackers abuse web pages that allow users to upload files to the
web server. If the input is not correctly sanitized, it may be possible to
upload an arbitrary php script and get it executed.

There were multiple attacks based on this scenario.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Mail server recently became an open relay

[John Fawcett]

On 19/10/2020 20:50, Rich Wales wrote:
> John Fawcett wrote:
>
>> One thing I would suggest looking at is if there is a web server running
>> on the same host it may be allowing email to be injected into postfix
>> via smtp on the loopback interface using some scripting language like
>> php or others.
> I suppose that's possible.
>
> I spent some time last night cleaning up old stuff from the server in
> question -- and also rebooting the box for good measure -- so the
> problem *might* just go away at this point.
>
> Before I can say anything more about this, unfortunately, I'll probably
> need to wait for another incident similar to the preceding ones, and try
> to capture more evidence while the problem is ongoing.  If it never
> happens again, then maybe it was the fault of an old PHP web page which
> I have removed.
>
> If the problem were in fact due to a hijacked PHP page, btw, would this
> necessarily require the page to be using e-mail or TCP connections
> already for its own legitimate purposes, but being co-opted by a hacker
> to nefarious ends?  Or could *any* PHP script theoretically be infected
> in a way that would cause this misbehaviour?
>
> Rich Wales
> ri...@richw.org

Sorry not to be able to give a definitive answer. Typical mail injection
via php will use a script that already calls the php mail function or
similar functions that open the smtp connection. But there are other
attack vectors that are possible that allow hackers to gain the
privileges of the web server user. The web server user is often allowed
to inject mail to localhost without any authentication (under the
permit_mynetworks syntax in postfix main.cf).

John

Re: Mail server recently became an open relay

[Rich Wales]

John Fawcett wrote:

> One thing I would suggest looking at is if there is a web server running
> on the same host it may be allowing email to be injected into postfix
> via smtp on the loopback interface using some scripting language like
> php or others.

I suppose that's possible.

I spent some time last night cleaning up old stuff from the server in
question -- and also rebooting the box for good measure -- so the
problem *might* just go away at this point.

Before I can say anything more about this, unfortunately, I'll probably
need to wait for another incident similar to the preceding ones, and try
to capture more evidence while the problem is ongoing.  If it never
happens again, then maybe it was the fault of an old PHP web page which
I have removed.

If the problem were in fact due to a hijacked PHP page, btw, would this
necessarily require the page to be using e-mail or TCP connections
already for its own legitimate purposes, but being co-opted by a hacker
to nefarious ends?  Or could *any* PHP script theoretically be infected
in a way that would cause this misbehaviour?

Rich Wales
ri...@richw.org

Re: Mail server recently became an open relay

[John Fawcett]

On 18/10/2020 06:32, Viktor Dukhovni wrote:
> On Sat, Oct 17, 2020 at 09:14:50PM -0700, Rich Wales wrote:
>
>> Thanks.  I was actually thinking something of the sort myself -- my
>> server is indeed behind a separate firewall appliance.
>>
>> However, other e-mail (such as your recent reply to my inquiry) is NOT
>> exhibiting this same NAT/proxy addressing problem.  The relevant
>> "Received:" line in my copy of your reply says the following (with line
>> wrapping to make it legible in an ASCII environment):
> Well, that shows that a proxy is the more likely scenario, some process
> listening on a non-loopback IP that passes SMTP connections through to
> 127.0.0.1, or a NAT rule in your iptables...
>
>> I'll continue searching for any possible security hole on my firewall
>> appliance, though.
> The firewall appliance (if a separate device) cannot make connections
> appear to originate from 127.0.0.1, only something running on your
> machine itself can do that.  So not much point looking there.
>
One thing I would suggest looking at is if there is a web server running
on the same host it may be allowing email to be injected into postfix
via smtp on the loopback interface using some scripting language like
php or others.

John

Re: Mail server recently became an open relay

[Viktor Dukhovni]

On Sat, Oct 17, 2020 at 09:14:50PM -0700, Rich Wales wrote:

> Thanks.  I was actually thinking something of the sort myself -- my
> server is indeed behind a separate firewall appliance.
> 
> However, other e-mail (such as your recent reply to my inquiry) is NOT
> exhibiting this same NAT/proxy addressing problem.  The relevant
> "Received:" line in my copy of your reply says the following (with line
> wrapping to make it legible in an ASCII environment):

Well, that shows that a proxy is the more likely scenario, some process
listening on a non-loopback IP that passes SMTP connections through to
127.0.0.1, or a NAT rule in your iptables...

> I'll continue searching for any possible security hole on my firewall
> appliance, though.

The firewall appliance (if a separate device) cannot make connections
appear to originate from 127.0.0.1, only something running on your
machine itself can do that.  So not much point looking there.

-- 
Viktor.

Re: Mail server recently became an open relay

[Rich Wales]

> No, it says no such thing.  It says the EHLO name was [154.91.34.144],
> the client IP was however 127.0.0.1.  It seems you have some sort of
> proxy or NAT in place that masks the real external IP address, making
> all connections appear to originate from 127.0.0.1.  That would sure
> explain your spam innundation problem.

Thanks.  I was actually thinking something of the sort myself -- my
server is indeed behind a separate firewall appliance.

However, other e-mail (such as your recent reply to my inquiry) is NOT
exhibiting this same NAT/proxy addressing problem.  The relevant
"Received:" line in my copy of your reply says the following (with line
wrapping to make it legible in an ASCII environment):

Received: from english-breakfast.cloud9.net
(english-breakfast.cloud9.net [168.100.1.7])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by memoryalpha.richw.org (Postfix)
with ESMTPS id 4CDQt72CNxz7t88
for ; Sat, 17 Oct 2020 20:51:27 -0700 (PDT)

Your e-mail (along with lots and lots of valid e-mail) appears to be
entering my server via exactly the same NAT/proxy path as the spam did.

I'll continue searching for any possible security hole on my firewall
appliance, though.

Rich Wales
ri...@richw.org

Re: Mail server recently became an open relay

[Viktor Dukhovni]

On Sat, Oct 17, 2020 at 08:41:25PM -0700, Rich Wales wrote:

> Received: from memoryalpha.richw.org ([127.0.0.1])
>     by localhost (memoryalpha.richw.org [127.0.0.1]) (amavisd-new, port 
> 10024)
>     with ESMTP id D0t9j6VORyNH for ;
>     Thu, 15 Oct 2020 14:48:06 -0700 (PDT)
> Received: from [154.91.34.144] (localhost [127.0.0.1])
>     by memoryalpha.richw.org (Postfix) with ESMTP id 4CC2vp5WmFz87Jy
>     for ; Thu, 15 Oct 2020 14:48:06 -0700 (PDT)
> From: ScotiaInfoAlerts Communications 
> 
> Message-Id: <4cc2vp5wmfz8...@memoryalpha.richw.org>
> 
> Note that the chronologically last "Received:" line says the message was
> received from 154.91.34.144 -- an IP address with no hostname, in a
> range assigned (according to WHOIS) to Hong Kong.

No, it says no such thing.  It says the EHLO name was [154.91.34.144],
the client IP was however 127.0.0.1.  It seems you have some sort of
proxy or NAT in place that masks the real external IP address, making
all connections appear to originate from 127.0.0.1.  That would sure
explain your spam innundation problem.

> I'm not sure what the parenthesized reference to "(localhost
> [127.0.0.1])" in this "Received:" line means.  Does this mean that the
> client host falsely identified itself with "HELO localhost"?

No, the other way around.

> Oct 15 14:48:06 memoryalpha postfix/postscreen[18030]: CONNECT from
> [127.0.0.1]:52138 to [127.0.0.1]:25

Same NAT or proxy issue.

-- 
Viktor.

Re: Mail server recently became an open relay

[Rich Wales]

Sorry, when I said "chronologically last 'Received:' line" in my earlier
e-mail, I meant to say "chronologically first (physically last)".  Mea
culpa.

Rich Wales
ri...@richw.org

Re: Mail server recently became an open relay

[Rich Wales]

> /Show evidence (logging) and turn of verbose logging. Wietse/

OK, here is the message header for one of the spam e-mails (which did
not get deleted during my mass cleanup efforts because a copy was saved
in my amavisd-new quarantine database):

X-Envelope-From: 
X-Envelope-To: 
X-Envelope-To-Blocked: 
X-Quarantine-ID: 
X-Spam-Flag: YES
X-Spam-Score: 5.488
X-Spam-Level: *
X-Spam-Status: Yes, score=5.488 tag=x tag2=4.5 kill=4.5
tests=[ALL_TRUSTED=-1,
    BAYES_00=-0.8, BAYES_00_RAZOR=0.8, FSL_BULK_SIG=0.001,
    HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_HTML_ONLY=1,
    RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=3, SUBJ_ALL_CAPS=0.5]
    autolearn=disabled
Received: from memoryalpha.richw.org ([127.0.0.1])
    by localhost (memoryalpha.richw.org [127.0.0.1]) (amavisd-new,
port 10024)
    with ESMTP id D0t9j6VORyNH for ;
    Thu, 15 Oct 2020 14:48:06 -0700 (PDT)
Received: from [154.91.34.144] (localhost [127.0.0.1])
    by memoryalpha.richw.org (Postfix) with ESMTP id 4CC2vp5WmFz87Jy
    for ; Thu, 15 Oct 2020 14:48:06 -0700 (PDT)
From: ScotiaInfoAlerts Communications

Content-Type: text/html
To: andrea_ma...@yahoo.ca
Content-Transfer-Encoding: 7bit
X-Read: MailingV.4371434NJ
Subject: CONFIRMATION REQUIRED - CUSTOMER ID: SS437143
Message-Id: <4cc2vp5wmfz8...@memoryalpha.richw.org>
Date: Thu, 15 Oct 2020 14:48:06 -0700 (PDT)

Note that the chronologically last "Received:" line says the message was
received from 154.91.34.144 -- an IP address with no hostname, in a
range assigned (according to WHOIS) to Hong Kong.

I'm not sure what the parenthesized reference to "(localhost
[127.0.0.1])" in this "Received:" line means.  Does this mean that the
client host falsely identified itself with "HELO localhost"?

Now, here are the lines in my mail log corresponding to this message:

Oct 15 14:48:06 memoryalpha postfix/postscreen[18030]: CONNECT from
[127.0.0.1]:52138 to [127.0.0.1]:25
Oct 15 14:48:06 memoryalpha postfix/postscreen[18030]: WHITELISTED
[127.0.0.1]:52138
Oct 15 14:48:06 memoryalpha postfix/smtpd[6414]: connect from
localhost[127.0.0.1]
Oct 15 14:48:06 memoryalpha postfix/smtpd[6414]: 4CC2vp5WmFz87Jy:
client=localhost[127.0.0.1]
Oct 15 14:48:06 memoryalpha postfix/cleanup[7158]: 4CC2vp5WmFz87Jy:
message-id=<4cc2vp5wmfz8...@memoryalpha.richw.org>
Oct 15 14:48:06 memoryalpha postfix/qmgr[26090]: 4CC2vp5WmFz87Jy:
from=, size=9292,
nrcpt=1 (queue active)
Oct 15 14:48:08 memoryalpha amavis[8375]: (08375-11) Blocked SPAM
{DiscardedOpenRelay,Quarantined}, [127.0.0.1]:52138
 ->
, quarantine: D0t9j6VORyNH, Queue-ID:
4CC2vp5WmFz87Jy, Message-ID:
<4cc2vp5wmfz8...@memoryalpha.richw.org>, mail_id: D0t9j6VORyNH,
Hits: 5.488, size: 9276, 1290 ms
Oct 15 14:48:08 memoryalpha postfix/smtp[8703]: 4CC2vp5WmFz87Jy:
to=, relay=127.0.0.1[127.0.0.1]:10024,
delay=1.5, delays=0.19/0/0/1.3, dsn=2.7.0, status=sent (250 2.7.0
Ok, discarded, id=08375-11 - spam)

(plus some more amavis-specific log lines which I assume people here
don't care about).

Note here that the "client=" line (first line in the above) gives the
sending host as "localhost[127.0.0.1]".  I know that Postfix connects to
amavisd-new via [127.0.0.1]:10024, so I can understand references to
this IP address in and after the "amavis[8375]" log line.  But why does
the very first line (smtpd[6414], before any amavis processing) have
localhost as the client?

If my server is getting confused and thinks the message in question
originally came from localhost, I can easily understand why the open
relay checks are being skipped, since my main.cf file includes
127.0.0.0/8 amongst the "mynetworks" values.

So, am I doing something wrong that is allowing spammers to say "HELO
localhost" and get away with it?  Or is something else causing my
Postfix to think the e-mail came inbound from localhost even though it
didn't?

Other, valid e-mail coming into and delivered via this server retain the
sending host's identity, btw, and are not rewritten to claim they came
from localhost.

Rich Wales
ri...@richw.org

Re: Mail server recently became an open relay

[Wietse Venema]

Rich Wales:
> > Why do you believe that your server is an open relay, as in, it
> > will forward messages FROM spammers TO remote destinations.
> > Wietse
> 
> Because it *is* accepting messages from outsiders (spammers) and is
> using my server to relay those messages to remote destinations.  It was
> (and still is) my understanding that such messages should be rejected by
> Postfix during the SMTP dialogue, with an error to the client saying
> relay access is denied -- though I assume I inadvertently either failed
> to enable this check or have somehow broken it.

Show evidence (logging) and turn of verbose logging.

Wietse

Re: Mail server recently became an open relay

[Rich Wales]

On 2020-10-16 21:16, Bill Cole wrote:

> Based on your config and descriptions, it smells like a compromised
> account being used to pump mail through your submission service. A full
> set of log lines for one of the messages should reveal that. The
> master.cf lines for smtpd and submission would also help.

Thanks.  I'll look into this.

Rich Wales
ri...@richw.org

Re: Mail server recently became an open relay

[Bill Cole]

On 16 Oct 2020, at 18:20, Rich Wales wrote:


Hi.  My mail server (memoryalpha.richw.org), running Postfix 3.3.0,
recently started attracting open relay spam.  I thought I had done all
the appropriate things in Postfix to block open relay traffic, and I
hadn't seen any such traffic for a very long time, but suddenly I've
gotten three attacks in the last two days (plus another one a couple 
of

weeks ago).

I'm attaching the output of "postconf -nf".

You'll note that I'm using amavisd-new as a spam filter (which has
worked fine for a very long time).  The log info from amavisd-new
identifies the messages in question as probably coming via an open
relay, but it still passes them.  What confuses me is that I would
expect Postfix to have identified and rejected these messages during 
the

initial SMTP dialogue with the sender, and they should never reach
amavisd-new.

Any suggestions gratefully welcome.


Based on your config and descriptions, it smells like a compromised 
account being used to pump mail through your submission service. A full 
set of log lines for one of the messages should reveal that. The 
master.cf lines for smtpd and submission would also help.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Mail server recently became an open relay

[Viktor Dukhovni]

On Oct 16, 2020, at 11:17 PM, Rich Wales  wrote:
> 
> No, Viktor, I have not deleted my logs.  However, there is so much stuff
> in the Postfix log (/var/log/mail.log on my system) -- including both
> good e-mail messages and bad, overlapped every which-way, multiple
> Postfix processes, etc. -- that I don't think I can reasonably hope for
> anyone to be able to decipher even a time-delimited excerpt.

Well, of course I wasn't asking for the raw log file, just a sample of
a few problem messages...

> Are there any tools available to make sense of the Postfix log?  In the
> DEBUG_README document, there is mention of something called postfinger,
> but it appears to be missing (the ftp.wl0.org site is nonexistent).

https://github.com/vdukhovni/postfix/tree/master/postfix/auxiliary/collate

> I've enabled verbosity (smtpd -v) for the "smtpd" line in my master.cf,
> in hopes that this may capture some additional detail of inbound SMTP
> sessions.  Any other debugging suggestions would be welcomed.

No, turn that off.  It just makes it much harder to see the important
bits.

-- 
Viktor.

Re: Mail server recently became an open relay

[Rich Wales]

No, Viktor, I have not deleted my logs.  However, there is so much stuff
in the Postfix log (/var/log/mail.log on my system) -- including both
good e-mail messages and bad, overlapped every which-way, multiple
Postfix processes, etc. -- that I don't think I can reasonably hope for
anyone to be able to decipher even a time-delimited excerpt.

Are there any tools available to make sense of the Postfix log?  In the
DEBUG_README document, there is mention of something called postfinger,
but it appears to be missing (the ftp.wl0.org site is nonexistent).

I've enabled verbosity (smtpd -v) for the "smtpd" line in my master.cf,
in hopes that this may capture some additional detail of inbound SMTP
sessions.  Any other debugging suggestions would be welcomed.

I'll be back when I have something reasonably useful for you to look at.

Rich Wales
ri...@richw.org

Re: Mail server recently became an open relay

[Viktor Dukhovni]

On Oct 16, 2020, at 10:28 PM, Rich Wales  wrote:
> 
> The next time I see this happen -- could be tomorrow, could be weeks
> from now, I have no idea when -- I'll gladly forward a copy of my
> "mailq" output.  I deleted my earlier evidence, I'm afraid.

No "mailq" output needed.  Just the relevant entries from your logs.
Have you deleted your logs?

Also of course your configuration, per:

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

-- 
Viktor.

Re: Mail server recently became an open relay

[Rich Wales]

> Why do you believe that your server is an open relay, as in, it
> will forward messages FROM spammers TO remote destinations.
> Wietse

Because it *is* accepting messages from outsiders (spammers) and is
using my server to relay those messages to remote destinations.  It was
(and still is) my understanding that such messages should be rejected by
Postfix during the SMTP dialogue, with an error to the client saying
relay access is denied -- though I assume I inadvertently either failed
to enable this check or have somehow broken it.

I've run several open relay test sites on my server, and all of them
claim it is clean, but I have seen numerous mail queue listings with
such messages clogging up my system because the destination sites are
correctly identifying them as being relayed and won't accept them.  I
didn't think such messages were supposed to make it into the queue, but
should instead have been rejected by me with an SMTP error sent back to
the sending client.  One of these incidents, btw (two weeks ago),
created a mail queue of over 50,000 messages before I noticed it and
cleaned up the mess.  It took about a day after that for my server to
get taken off the GBUDB blacklist site.

The next time I see this happen -- could be tomorrow, could be weeks
from now, I have no idea when -- I'll gladly forward a copy of my
"mailq" output.  I deleted my earlier evidence, I'm afraid.

Rich Wales
ri...@richw.org

Re: Mail server recently became an open relay

[lists]

I would think running an open relay test would be step one. 

https://mxtoolbox.com/diagnostic.aspx


There are probably half a dozen online services that do this. Which brings me 
to my question: Is there an open relay test website that is considered the 
best? I have noticed some run multiple tests which I assume means different 
methods. 





  Original Message  


From: wie...@porcupine.org
Sent: October 16, 2020 3:27 PM
To: postfix-users@postfix.org
Reply-to: postfix-users@postfix.org
Subject: Re: Mail server recently became an open relay


Rich Wales:
> Hi.  My mail server (memoryalpha.richw.org), running Postfix 3.3.0,
> recently started attracting open relay spam.  I thought I had done all

Why do you believe that your server is an open relay, as in, it
will forward messages FROM spammers TO remote destinations.

Wietse

Re: Mail server recently became an open relay

[Wietse Venema]

Rich Wales:
> Hi.  My mail server (memoryalpha.richw.org), running Postfix 3.3.0,
> recently started attracting open relay spam.  I thought I had done all

Why do you believe that your server is an open relay, as in, it
will forward messages FROM spammers TO remote destinations.

Wietse

Mail server recently became an open relay

[Rich Wales]

Hi.  My mail server (memoryalpha.richw.org), running Postfix 3.3.0,
recently started attracting open relay spam.  I thought I had done all
the appropriate things in Postfix to block open relay traffic, and I
hadn't seen any such traffic for a very long time, but suddenly I've
gotten three attacks in the last two days (plus another one a couple of
weeks ago).

I'm attaching the output of "postconf -nf".

You'll note that I'm using amavisd-new as a spam filter (which has
worked fine for a very long time).  The log info from amavisd-new
identifies the messages in question as probably coming via an open
relay, but it still passes them.  What confuses me is that I would
expect Postfix to have identified and rejected these messages during the
initial SMTP dialogue with the sender, and they should never reach
amavisd-new.

Any suggestions gratefully welcome.

Rich Wales
ri...@richw.org
alias_maps = hash:/etc/aliases
append_dot_mydomain = yes
compatibility_level = 2
default_destination_concurrency_limit = 1
default_destination_recipient_limit = 1
disable_vrfy_command = yes
enable_long_queue_ids = yes
fast_flush_domains =
hopcount_limit = 150
inet_protocols = ipv4
lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3
lmtp_tls_protocols = !SSLv2, !SSLv3
local_destination_concurrency_limit = 1
local_destination_recipient_limit = 1
local_recipient_maps = $alias_maps
mail_owner = postfix
mailbox_transport = lmtp:[127.0.0.1]
maximal_queue_lifetime = 30d
message_size_limit = 5000
message_strip_characters = \0
milter_default_action = accept
milter_protocol = 2
mydestination = richw.org, richw.ca, pcre:/etc/postfix/richw_subdomains,
localhost, marywalesloomis.com
mydomain = richw.org
myhostname = memoryalpha.richw.org
mynetworks = 127.0.0.0/8, 10.0.229.0/24, 96.82.71.8/29,
mynetworks_style = subnet
myorigin = $myhostname
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_bare_newline_action = ignore
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_max_ttl = 3h
postscreen_dnsbl_min_ttl = 30m
postscreen_dnsbl_sites = whitelist.richw.org=127.0.0.1*-100,
hostkarma.junkemailfilter.com=127.0.0.1*-30,
score.senderscore.com=127.0.4.[91..100]*-30,
score.senderscore.com=127.0.4.[71..90]*-24,
list.dnswl.org=127.0.[0..255].3*-16, list.dnswl.org=127.0.[0..255].2*-8,
list.dnswl.org=127.0.[0..255].1*-4, list.dnswl.org=127.0.[0..255].0*-2,
blacklist.richw.org=127.0.0.2*100, zen.spamhaus.org=127.0.0.[2..255]*40,
dnsbl.justspam.org=127.0.0.[2..255]*20,
hostkarma.junkemailfilter.com=127.0.0.2*10, dyna.spamrats.com=127.0.0.36*9,
b.barracudacentral.org=127.0.0.2*8, truncate.gbudb.net=127.0.0.[2..255]*6,
rbl.megarbl.net=127.0.0.2*4, hostkarma.junkemailfilter.com=127.0.0.4*3,
psbl.surriel.com=127.0.0.[2..255]*2, dnsbl.sorbs.net=127.0.0.[2..255]*2,
bl.spamcop.net=127.0.0.[2..255]*2, multi.surbl.org=127.0.0.[2..255]*2
postscreen_dnsbl_threshold = 7
postscreen_dnsbl_whitelist_threshold = -16
postscreen_greet_action = enforce
postscreen_greet_banner = $myhostname Please stand by . . .
postscreen_non_smtp_command_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
relay_destination_recipient_limit = 1
relay_domains = indigo.richw.org, goldsmurf.randerzo.net
smtp_address_preference = ipv4
smtp_destination_concurrency_limit = 1
smtp_destination_recipient_limit = 1
smtp_reply_filter = pcre:/etc/postfix/reply_filter
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = PLAIN LOGIN
smtp_sasl_password_maps = hash:/etc/postfix/sasl_fallback
smtp_sasl_security_options = noanonymous
smtp_sender_dependent_authentication = no
smtp_tls_ciphers = medium
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = may
smtpd_banner = $smtpd_banner_regular
smtpd_banner_fallback = $smtpd_banner_regular (fallback)
smtpd_banner_regular = $myhostname ESMTP
smtpd_banner_submission = $smtpd_banner_regular (Postfix $mail_version --
submission)
smtpd_client_restrictions = permit_mynetworks, permit_dnswl_client
whitelist.richw.org=127.0.0.1, permit_rhswl_client
whitelist.richw.org=127.0.0.1, reject_rbl_client
blacklist.richw.org=127.0.0.2, reject_rhsbl_client
blacklist.richw.org=127.0.0.2, reject_rhsbl_client
dbl.spamhaus.org=127.0.1.[0..255]
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_discard_ehlo_keywords = dsn etrn size vrfy silent-discard
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_rhswl_client
whitelist.richw.org=127.0.0.1, reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname,
reject_rhsbl_helo blacklist.richw.org=127.0.0.2, reject_rhsbl_helo
dbl.spamhaus.org=127.0.1.[0..255]
smtpd_recipient_restrictions = per