Koozali.org: home of the SME Server
Contribs.org Forums => Koozali SME Server 10.x => Topic started by: Michail Pappas on June 17, 2022, 02:20:11 PM
-
Any ideas?
2022-06-17 11:58:34.481758500 18817 Accepted connection 2/40 from 84.205.251.179 / mail.synigoros.gr
2022-06-17 11:58:34.481932500 18817 Connection from mail.synigoros.gr [84.205.251.179]
2022-06-17 11:58:35.627736500 18817 (connect) earlytalker: pass, not spontaneous
2022-06-17 11:58:35.630252500 18817 (connect) relay: skip, no match
2022-06-17 11:58:35.695425500 18817 (connect) dnsbl: pass
2022-06-17 11:58:35.696090500 18817 220 mail.pieria.gr ESMTP
2022-06-17 11:58:35.710194500 18817 dispatching EHLO EXSRV01.SYNIGOROS2.LOCAL
2022-06-17 11:58:35.715113500 18817 (ehlo) helo: karma -1 (-1)
2022-06-17 11:58:35.715289500 18817 (ehlo) helo: fail, NAUGHTY, no such host
2022-06-17 11:58:35.716588500 18817 250-pieria.gr Hi mail.synigoros.gr [84.205.251.179]
2022-06-17 11:58:35.716721500 18817 250-PIPELINING
2022-06-17 11:58:35.716819500 18817 250-8BITMIME
2022-06-17 11:58:35.716921500 18817 250-SIZE 30000000
2022-06-17 11:58:35.717059500 18817 250-STARTTLS
2022-06-17 11:58:35.717160500 18817 250 AUTH PLAIN LOGIN
2022-06-17 11:58:35.728953500 18817 dispatching MAIL FROM:<abosd@synigoros.gr> SIZE=886086
2022-06-17 11:58:35.770021500 18817 (mail) resolvable_fromhost: pass, synigoros.gr has MX at mail3.synigoros.gr
2022-06-17 11:58:35.796156500 18817 (mail) sender_permitted_from: skip, tolerated, none, synigoros.gr: No applicable sender policy available
2022-06-17 11:58:35.796428500 18817 (mail) naughty: disconnecting
2022-06-17 11:58:35.796849500 18817 (deny) logging::logterse: ` 84.205.251.179 mail.synigoros.gr EXSRV01.SYNIGOROS2.LOCAL naughty 903 (helo) HELO hostname does not exist msg denied before queued
2022-06-17 11:58:35.797268500 18817 deny mail from <abosd@synigoros.gr> ((helo) HELO hostname does not exist)
2022-06-17 11:58:35.797407500 18817 550 (helo) HELO hostname does not exist
2022-06-17 11:58:35.797583500 18817 click, disconnecting
2022-06-17 11:58:35.858701500 1521 cleaning up after 18817
No special contribs, plain SME. My /etc/qpsmtpd/plugins:
#
# Example configuration file for plugins
#
# enable this to get configuration via http; see perldoc
# plugins/http_config for details.
# http_config http://localhost/~smtpd/config/ http://www.example.com/smtp.pl?config=
# tls should load before count_unrecognized_commands
# to support legacy port 465, tls must load before connection plugins
#tls
# hosts_allow does not work with the tcpserver deployment model!
# perldoc plugins/hosts_allow for an alternative.
#
# The hosts_allow module must be loaded if you want the -m / --max-from-ip /
# my $MAXCONNIP = 5; # max simultaneous connections from one IP
# settings... without this it will NOT refuse more than $MAXCONNIP connections
# from one IP!
hosts_allow
# connection / informational plugins
#connection_time
#karma penalty_box 1 reject naughty
ident/geoip
#ident/p0f /tmp/.p0f_socket version 3
fcrdns
quit_fortune
earlytalker
count_unrecognized_commands 4
relay
#whitelist
dnsbl reject naughty reject_type disconnect
rhsbl
# greylisting reject 0 p0f genre,windows
# HELO plugins
helo policy strict reject 0
# enable to reject MAIL FROM:/RCPT TO: parameters if client helo was HELO
# (strict RFC 821)... this is not used in EHLO ...
# parse_addr_withhelo
# AUTH plugins
#auth/auth_checkpassword checkpw /usr/local/vpopmail/bin/vchkpw true /usr/bin/true
#auth/auth_vpopmail
#auth/auth_vpopmaild
#auth/auth_vpopmail_sql
auth/auth_flat_file
auth/authdeny
# enable to accept MAIL FROM:/RCPT TO: addresses without surrounding <>
dont_require_anglebrackets
# MAIL FROM plugins
badmailfrom reject naughty
#badmailfromto
resolvable_fromhost reject 0
sender_permitted_from reject 1
# RCPT TO plugins
badrcptto
#qmail_deliverable
# this plugin needs to run after all other "rcpt" plugins
rcpt_ok
# DATA plugins
#uribl
headers reject 0 reject_type temp require From,Date future 2 past 15
bogus_bounce log
#loop
dkim reject 0
# dmarc requires dkim and SPF to run before it
dmarc
# content filters
virus/klez_filter
# You can run the spamassassin plugin with options. See perldoc
# plugins/spamassassin for details.
#
spamassassin reject 12
# rejects mails with a SA score higher than 20 and munges the subject
# of the score is higher than 10.
#
# spamassassin reject 20 munge_subject_threshold 10
# dspam must run after spamassassin for the learn_from_sa feature to work
dspam autolearn spamassassin reject 0.95
# run the clamav virus checking plugin (max size in Kb)
# virus/clamav
# virus/clamdscan deny_viruses yes max_size 1024
naughty reject data
# You must enable a queue plugin - see the options in plugins/queue/ - for example:
# queue to a maildir
# queue/maildir /home/spamtrap/mail
# queue the mail with qmail-queue
# queue/qmail-queue
# forward to another mail server
# queue/smtp-forward 10.2.2.2 9025
# If you need to run the same plugin multiple times, you can do
# something like the following
# relay
# relay:0 somearg
# relay:1 someotherarg
-
Right in front of you.
2022-06-17 11:58:35.797268500 18817 deny mail from <abosd@synigoros.gr> ((helo) HELO hostname does not exist)
2022-06-17 11:58:35.797407500 18817 550 (helo) HELO hostname does not exist
2022-06-17 11:58:35.797583500 18817 click, disconnecting
They have a badly set up mail server. Tell them to fix their HELO name.
-
their hostname is EXSRV01.SYNIGOROS2.LOCAL
the smtp server should identify with a resolvable address.
can you tell
rpm -q smeserver-qpsmtpd
-
Hey lads, thank for the quick response.
Right in front of you.
2022-06-17 11:58:35.797268500 18817 deny mail from <abosd@synigoros.gr> ((helo) HELO hostname does not exist)
2022-06-17 11:58:35.797407500 18817 550 (helo) HELO hostname does not exist
2022-06-17 11:58:35.797583500 18817 click, disconnecting
They have a badly set up mail server. Tell them to fix their HELO name.
That was my initial impression. However, there's a danger of legal action here, in case we do not receive messages that we are supposed to. So I tried to make sense of the SMTP RFC. At https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.4 there's the following passage:
An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis. Information captured in the
verification attempt is for logging and tracing purposes. Note that
this prohibition applies to the matching of the parameter to its IP
address only; see Section 7.9 for a more extensive discussion of
rejecting incoming connections or mail messages.
I'm definitely not an expert here. In other cases, for example when the sending server does not have an rDNS entry IIRC that is a legitimate reason to block traffic. In that case the receiver is in the clear.
But in this scenario I must be extra carefull: if the shit hits the fan and I have to prove that blocking the message was not 100% my fault. This has already happened from the same sender over the last 2-3 weeks, but got informed today in a rather unfriendly tone from the organization head... :(
their hostname is EXSRV01.SYNIGOROS2.LOCAL
the smtp server should identify with a resolvable address.
can you tell
rpm -q smeserver-qpsmtpd
smeserver-qpsmtpd-2.7.0-7.el7.sme.noarch
The bottomline is that if this is a misconfiguration but one that I must not act upon by rejecting, then I'll simply try to inform the admins from the sender side and on my sme box simply whitelist their servers...
-
I seem to recall you have had the same issue with other people before.
Their server does not have a rDNS.
It's up to you whether you accept it.
I don't as it is a normal spam vector. YMMV.
So disabling it will open the flood gates to a lot more spam. That is your choice.
However, if there is a legal aspect then they should get their act together and use a compliant well configured server.
Like to see them send to say M$ or Google..... Almost certainly rejected.
-
67 * Thu Feb 10 2022 Jean-Philippe Pialasse <tests@pialasse.com> 2.7.0-8.sme
68 - fix regression Set the default helo policy to lenient [SME: 11864]
69
without forcing you to get all the updates in smeupdates-testing you ahould at leat get that one.
indeed the curent version is more strict that what is asking rfc
-
@Jean some questions, please bear with me:
1) Instead of installing 2.7.0.8 can I simply do a:
db configuration setprop qpsmtpd HeloPolicy lenient
to accomplish the same thing? I'm asking because I'm wondering a bit here: if this fix was much needed wouldn't this patch be in updates instead of updates-testing?
2) I've got the wbl contrib. Would another approach be to simply whitelist the hosts in this case to get the job done?
3) With a lenient policy this message would not be blocked obviously. Would it be blocked if I switched to rfc instead of strict?
IIRC the lenient policy would let too much spam pass. Since I came from SME9 with a lenient policy for years I definitely concur with that observation. On the other hand I do want to block bad traffic, but without raising legal issues for blocking...
-
to accomplish the same thing? I'm asking because I'm wondering a bit here: if this fix was much needed wouldn't this patch be in updates instead of updates-testing?
This was the bug that changed that setting - https://bugs.koozali.org/show_bug.cgi?id=11864, smeserver-qpsmtpd-2.7.0-8.el7.sme.noarch.rpm, verified back in Feb..since then there have been another 3 Bugs resolved and verified, now at smeserver-qpsmtpd-2.7.0-11.el7.sme.noarch.rpm, put it down to caution (or the few were occupied elsewhere) those who like to walk on the wild side have been happy to date (fingers crossed) look for latest to be available in updates shortly
-
You guys, always there for us and always informative! Thumbs up!
I'll install 2.7.0-8 then.
-
you will have to go to -9
Added - it and 8 very similar, -9 is safe :-)
* Tue Apr 05 2022 Jean-Philippe Pialasse <tests@pialasse.com> 2.7.0-9.sme
- add softlimit template for qpsmtpd [SME: 11858]
increase softlimit to 50000000.
* Thu Feb 10 2022 Jean-Philippe Pialasse <tests@pialasse.com> 2.7.0-8.sme
- fix regression Set the default helo policy to lenient [SME: 11864]
-
with all that, very shortly latest update will be in updates along with a handful of others that have been worked over last few weeks/month
-
Awesome work fellas, congrats again! :pint: :pint: :pint:
-
Something I must be doing wrong here. I've installed the -9 package with:
yum update-to smeserver-qpsmtpd-2.7.0-9.el7.sme.noarch --enablerepo=smeupdates-testing
Not sure if update-to was proper here or not, I was not sure how to update to an interim version. In any case:
# rpm -q smeserver-qpsmtpd
smeserver-qpsmtpd-2.7.0-9.el7.sme.noarch
Funny thing is that I was not prompted to do the signal-event post-upgrade and reboot cycle. I did so, but nothing happened. /etc/qpsmtpd/plugins remained the same:
# ls -laFt /etc/qpsmtpd/plugins
-rw-r--r-- 1 root root 2951 Nov 17 2021 /etc/qpsmtpd/plugins
Furthermore, in /etc/qpsmtpd/plugins policy seems to be still set to strict:
...
# HELO plugins
helo policy strict reject 0
Looking things more closely, wasn't rfc the default behaviour up to -7? Why is it set here as strict?
My qpsmtpd configuration:
# config show qpsmtpd
qpsmtpd=service
Authentication=enabled
Bcc=disabled
BccMode=cc
BccUser=maillog
DKIMSigning=enabled
DMARCContactInfo=http://myhost/
DMARCReject=enabled
DMARCReportEmail=admin@mydomain
DNSBL=enabled
HeloHost=myhost
Instances=40
InstancesPerIP=5
LogLevel=6
MaxScannerSize=25000000
MaximumDateOffset=0
PatternsScan=enabled
Proxy=blocked
RBLList=bl.spamcop.net,psbl.surriel.com,zen.spamhaus.org
RHSBL=disabled
RelayRequiresAuth=enabled
SBLList=multi.surbl.org,rhsbl.sorbs.net
TCPPort=25
TCPProxyPort=25
TlsBeforeAuth=0
UBLList=multi.surbl.org:8-16-64-128,black.uribl.com,rhsbl.sorbs.net
URIBL=disabled
VirusScan=enabled
access=public
qplogsumm=enabled
status=enabled
tnef2mime=enabled
I have the WBL contrib installed, could it be doing something to my general setup here?
-
Doh! I was looking at the wrong place. It seems that files affected were under /var/service/qpsmtpd/config/peers:
# grep -R "policy" /var/service/qpsmtpd/config/peers/
/var/service/qpsmtpd/config/peers/0:helo policy lenient reject naughty
/var/service/qpsmtpd/config/peers/0:sender_permitted_from reject 1 no_dmarc_policy 0
/var/service/qpsmtpd/config/peers/myip:helo policy lenient reject naughty
/var/service/qpsmtpd/config/peers/myip:sender_permitted_from reject 1 no_dmarc_policy 0
What is the /etc/qpsmtpd and plugins/ hierarchy used for, if stuff is under /var/service/qpsmtpd ?
-
we only use the /var/service for historical reasons (runit / daemontools)
-
I'm sorry but I do not understand. Which settings are used? The ones under /etc/qpsmtpd or the ones under /var/service/qpsmtpd ?
-
I'm sorry but I do not understand. Which settings are used? The ones under /etc/qpsmtpd or the ones under /var/service/qpsmtpd ?
what is unclear in
we only use the /var/service
-
what is unclear in
The "... for historical reasons" part threw me off, thanks for the clarification.
-
The admins of this server responded very fast, by contacting me and fixing the EHLO part (even though qpsmtpd has a lenient helo policy). Their box is an Exchange system, recently updated to the 2019 version.
Now incoming messages fail, due to some sort of TLS issue:
2022-06-20 13:34:08.235379500 3360 Accepted connection 1/40 from 84.205.251.179 / mail.synigoros.gr
2022-06-20 13:34:08.235629500 3360 Connection from mail.synigoros.gr [84.205.251.179]
2022-06-20 13:34:09.381734500 3360 (connect) earlytalker: pass, not spontaneous
2022-06-20 13:34:09.384584500 3360 (connect) relay: skip, no match
2022-06-20 13:34:09.631119500 3360 (connect) dnsbl: pass
2022-06-20 13:34:09.631820500 3360 220 myhost ESMTP
2022-06-20 13:34:09.645727500 3360 dispatching EHLO mail.synigoros.gr
2022-06-20 13:34:09.648011500 3360 (ehlo) helo: pass
2022-06-20 13:34:09.648012500 3360 250-mydomain Hi mail.synigoros.gr [84.205.251.179]
2022-06-20 13:34:09.648012500 3360 250-PIPELINING
2022-06-20 13:34:09.648013500 3360 250-8BITMIME
2022-06-20 13:34:09.648013500 3360 250-SIZE 30000000
2022-06-20 13:34:09.648013500 3360 250-STARTTLS
2022-06-20 13:34:09.648013500 3360 250 AUTH PLAIN LOGIN
2022-06-20 13:34:09.660061500 3360 dispatching STARTTLS
2022-06-20 13:34:09.660209500 3360 220 Go ahead with TLS
2022-06-20 13:34:09.677251500 3360 (deny) logging::logterse: ` 84.205.251.179 mail.synigoros.gr mail.synigoros.gr tls 901 TLS Negotiation Failed msg denied before queued
2022-06-20 13:34:09.677456500 3360 500 TLS Negotiation Failed
Does anyone have any experience with this M$ BS? What should I be looking for?
EDIT: Is this possibly related to this? https://bugs.koozali.org/show_bug.cgi?id=11550
-
It seems that upon unsuccesful try, the sending server re-sends without encryption. I've received the message, so it is alright I presume?
(Mental note: I see that my box receives Gmail with TLS from the looks of it, so perhaps there's something at work with the exchange that does not allow sending over TLS to my box? )
-
you can increase log verbosity. see wiki to find how.
However from what you show the sending smtp tries to login as user with password.
250 AUTH PLAIN LOGIN
It is not supposed to do so. This is only for your client this option.
-
(Mental note: I see that my box receives Gmail with TLS from the looks of it, so perhaps there's something at work with the exchange that does not allow sending over TLS to my box? )
I found this KB article from Microsoft saying Exchange 2019 uses TLS1.0 & TLS1.1 until a patch is installed:
https://support.microsoft.com/en-us/topic/tls-1-2-is-not-set-as-default-after-you-install-exchange-2019-with-edge-transport-role-kb5004617-fbf80ea2-365c-4a19-bbcc-7ac7b87f58d7
Security settings for outbound email delivery from gmail can be seen here (scroll down to "Outbound server ciphers"):
https://support.google.com/a/answer/9795993?hl=en
If your SME server is configure to allow only TLS1.2, an unpatched Exchange 2019 server would not be able to connect.
-
thanks Mmccarn
this is SME 10 default considering you might accept auth.
Michail, you will start to prove helpfull to your contact in helping him configuring his server.
-
@mmccarn thanks for the info!
Coupled with what Jean advised, I've got a level 8 dump from the same sender, but I did not have time to sanitize and upload here. What's strange though is that this time there was no double sending of the file... Not sure why that happened, or whether I've missed the second, plaintext version of the message. Up to and including Wednesday I've got some pretty difficult days coming up.
But it will be a good thing to be able to help those guys fix their server: their organization is a NGO dealing with consumer allegations of company wrongdoings...
-
perhaps they are good candidates to migrate to SME ;)
-
perhaps they are good candidates to migrate to SME ;)
With the amount of effort MS is trying to lure govmt and NGOs to Azure/E365 and other technologies, it's like trying to save people that have gone the Borg way :(
Anyways, this is the verbose log I've got: https://pastebin.com/R2KfJ1tU
Notice that there is no attempt to send TLS'ed first; the message here is sent directly plain if I understand correctly.
This domain has three MX servers though. This last one seems to have been sent from the third one, whereas the case with the problem originated from their first server. Any chance that the first server alone is misconfigured?