On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:
Hello,
I have a big problem, someone is using my mailserver for sending spam.
I
see it in de logs. I can block the IP but then they use other IP's.
So far I know my server is up-to-date and correct configured. And when
I
do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx
The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.
What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not
help.
All spam is recognizeble by this authenticated username.
In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):
----
Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
[87.92.55.206])
(Authenticated sender: p...@puk.nl)
by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
----
As would my server sent it to my server...
Not exactly. That Received header indicates that the machine at
87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
proceeded to authenticate as the user whose name you've replaced with
p...@puk.nl.
As a stopgap, you could add a directive like this to
smtpd_helo_restrictions:
check_helo_access pcre:/etc/postfix/helo_checks
And in that helo_checks file;
/127\.0\.0\.1/ REJECT you are not me
This will catch and reject formally correct IP literals as in this case
and the more common bare IP form of claiming to be localhost. There's no
reason for any mail client ever to say "EHLO [127.0.0.1]" except to
cause a MTA to generate a confusing Received header.
Does somebody have a clou here?
With regards,
Paul van der Vlis.
Some settings and logs:
Those are inadequate to understand this problem.
See the bottom part of the Postfix DEBUG_README file, probably installed
on your machine with Postfix (maybe in both plaintext and HTML) and
always available on the Postfix website. It describes what information
is needed to effectively get help here. The welcome message you got when
you subscribed this list also referenced that document.
Paraphrasing the DEBUG_README and adapting its recommendations to this
issue, you should include:
Full 'postconf -nf' output
Full 'postconf -Mf' output
Full headers of a sample spam message, redacted only to protect *USER*
privacy. (Don't redact hostnames or IPs)
All log lines containing the Postfix queue id of the sample spam
message.
If your SASL layer logs authentication successes and failures (perhaps
in /var/log/auth.log) find the relevant log entries for the sample
message.
There is no need for verbose logging by Postfix.
