Mercury 4.91
Mercury S > transaction filter

I am unsure right now HOW the filter is applied.
My filter has a rule to drop the connection immediately when the remote server is announcing itself in the HELO command with localhost.

Using now roundcube and it announces itself with localhost AND the user is successful authenticated, the connection is still drop immediately.

The box underneath the filter "Successful AUTH exempts from filtering" is ticked, as shown in the image. But it is not applied to my successful authenticated user.

Do I missunderstand this, or is this not working correctly ?
To test this, I commented out the rule in the transaction filter and the message was send correctly. Activated it again, failure.

Johannes

Hi Johannes,
In our case both Mercury and Roundcube server/services are situated in our internal LAN and not directly accessable from the internet. Our colleagues have to establish a VPN connection firstly from their notebooks to Company LAN to get access to Roundcube service. Insofar we've got less security restrictions here with us. So please keep this in mind.

The Compliance tab in our Mercury SMTP settings is completely unchecked, means no single checkbox is activated. Roundcube works fine.

Hallo Joerg,

I think you misunderstood my point, or I described it not clear enough.
Roundcube and Mercury are working fine with each other. I also found a setting in roundcube's config file to set a HELO for announcing. But so far I hadn't done so and had added my "old" (12 years) transaction filter to Mercury.
And after adding the filter, I noticed the problem and did the testing.

The problem seems to be: the transaction filter is even applied when users are authenticated. Which should not be, if I understand the above described option (image) correct.

So, if I am correct in my understanding by ticking this option, than this is a bug in Mercury.
Maybe Rolf or David can shime in ?

Johannes

What does the transaction filter rule look like? To wait for AUTH it should be a 'D' rule:

'D' for deferred HELO processing; these filters will only be
applied if the client does not issue a successful AUTH after
issuing HELO but before issuing any other command. Otherwise,
these filters are the same as 'H' filters. They allow a user
on a system that might otherwise be rejected to redeem the
connection by authenticating his identity.

I had read this a few time to sink in.
I don't think that I need a D rule as the user is authenticated successfuly.

D' for deferred HELO processing; these filters will only be
applied if the client does not issue a successful AUTH

So, if the user authenticate successfuly, the D rule is not needed as these D rules will ONLY be applied if no successful authentication has taken place.
Am I wrong here?

I know that I have no D rules in the filter, as in the old filter, the D was a Drop action. There were no D rules.
The first lines

H, "[0-9]+.[0-9]+.[0-9]+.[0-9]", DS, "554 [0-9]+.[0-9]+.[0-9]+.[0-9]"
H, "[0-9]+.[0-9]+.[0-9]+.[0-9]+.", DS, "554 [0-9]+.[0-9]+.[0-9]+.[0-9]+."
H, "[0-9]+-[0-9]+-[0-9]+-[0-9]", DS, "554 [0-9]+-[0-9]+-[0-9]+-[0-9]"
H, "[0-9]+-[0-9]+-[0-9]+-[0-9]+.", DS, "554 [0-9]+-[0-9]+-[0-9]+-[0-9]+."
H, "-[0-9]+-[0-9]+-[0-9]+-[0-9]+.", DS, "554 -[0-9]+-[0-9]+-[0-9]+-[0-9]+."
H, "[0-9]+-[0-9]+-[0-9]", DS, "554 [0-9]+-[0-9]+-[0-9]"
H, "xyz34.uk.co.sg", DS, "554 xyz34.uk.co.sg"
H, "dsl", DS, "554 dsl"
H, "ppp", DS, "554 ppp"
H, "|", DS, "554 | "
H, ".ukl.yahoo.com", DS, " 554 ukl.yahoo.com"
H, "OfficeManager", DS, " 554 officemanager"
H, "localhost*", DS, "554 localhost"

Please try changing that rule to:

D, "localhost*", DS, "554 localhost"

Hello Rolf,

did change the rule and, as expected, the user is able to send.
But that does not answer my original question:

By ticking the box "Successful Auth exempts from filtering", as shown in my image above, a user should be able to send mail, even if the rule is set to H, "localhost", DS, "554 localhost". The transaction filter is not applied in the situation that the user has authenticated successfuly in MercuryS. Is that correct understood ?

Assuming, that it is correct understood by me, than using the D operation in this situation is just "helping to overcome" the error. And the error is, that the filter is applied even if the box "Successful Auth exempts from filtering" is ticked.

I did 3 tests and here are 2 session logs
Log 1
Box ticked "filter activated" and box ticked "Successful Auth exempts from filtering" and rule set with H operator
19:23:17.603: --- 15 Mar 2023, 19:23:17.603 ---
19:23:17.603: Accepted connection from '192.168.200.34', port 587, timeout 30 secs.
19:23:17.606: Connection from 192.168.200.34, Wed Mar 15, 19:23:17
19:23:17.606: << 220 mail.yorktondigital.ca ESMTP server ready.<cr><lf>
19:23:17.606: >> EHLO localhost<cr><lf>
19:23:17.611: --- Connection closed at 15 Mar 2023, 19:23:17.611. ---
19:23:17.611:

Log 2 with 2 tests
Box ticked "filter activated" and box ticked "Successful Auth exempts from filtering" and rule set with D operator
Box ticked "filter activated" and box not ticked "Successful Auth exempts from filtering" and rule set with D operator
19:19:22.240: --- 15 Mar 2023, 19:19:22.240 ---
19:19:22.240: Accepted connection from '192.168.200.34', port 587, timeout 30 secs.
19:19:22.242: Connection from 192.168.200.34, Wed Mar 15, 19:19:22
19:19:22.242: << 220 mail.yorktondigital.ca ESMTP server ready.<cr><lf>
19:19:22.242: >> EHLO localhost<cr><lf>
19:19:22.245: << 250-mail.yorktondigital.ca Hello localhost; ESMTPs are:<cr><lf>
19:19:22.245: << 250-TIME<cr><lf>
19:19:22.245: << 250-SIZE<cr><lf>
19:19:22.245: << 250-8BITMIME<cr><lf>
19:19:22.245: << 250-AUTH CRAM-MD5 LOGIN PLAIN<cr><lf>
19:19:22.245: << 250-AUTH=LOGIN<cr><lf>
19:19:22.246: << 250 HELP<cr><lf>
19:19:22.246: >> AUTH PLAIN<cr><lf>
19:19:22.246: << 334 Go ahead<cr><lf>
19:19:22.247: >> AG1lcmN1cnkAaGFycmlz<cr><lf>
19:19:22.247: << 235 Authentication successful.<cr><lf>
19:19:22.248: >> MAIL FROM:xxxxxxx@yyyyyyyyy.ca<cr><lf>
19:19:22.274: << 250 Sender OK - send RCPTs.<cr><lf>
19:19:22.274: >> RCPT TO:xxxxx@yyyyyy.ca<cr><lf>
19:19:22.275: << 250 Recipient OK - send RCPT or DATA.<cr><lf>
19:19:22.275: >> DATA<cr><lf>
19:19:22.276: << 354 OK, send data, end with CRLF.CRLF<cr><lf>
19:19:22.276: >> MIME-Version: 1.0<cr><lf>
19:19:22.277: >> Date: Wed, 15 Mar 2023 19:19:22 -0600<cr><lf>
19:19:22.277: >> From: mercury xxxxxxxx@yyyyyyyyy.ca<cr><lf>
19:19:22.277: >> To: Prost xxxxx@yyyyyyy.ca<cr><lf>
19:19:22.277: >> Subject: filter test<cr><lf>
19:19:22.277: >> Message-ID: 394c63a539c595ea2310ce50180861c1@yyyyyyyy.ca<cr><lf>
19:19:22.277: >> X-Sender: xxxxx@yyyyyyyy.ca<cr><lf>
19:19:22.277: >> Content-Type: multipart/alternative;<cr><lf>
19:19:22.277: >> boundary="=_572b847be8d8b40e2bb1945b6792fba2"<cr><lf>
19:19:22.278: >> <cr><lf>
19:19:22.278: >> --=_572b847be8d8b40e2bb1945b6792fba2<cr><lf>
19:19:22.278: >> Content-Transfer-Encoding: 7bit<cr><lf>
19:19:22.278: >> Content-Type: text/plain; charset=US-ASCII;<cr><lf>
19:19:22.279: >> format=flowed<cr><lf>
19:19:22.279: >> <cr><lf>
19:19:22.279: >> <cr><lf>
19:19:22.279: >> <cr><lf>
19:19:22.279: >> is this send?<cr><lf>
19:19:22.279: >> --=_572b847be8d8b40e2bb1945b6792fba2<cr><lf>
19:19:22.279: >> Content-Transfer-Encoding: quoted-printable<cr><lf>
19:19:22.279: >> Content-Type: text/html; charset=UTF-8<cr><lf>
19:19:22.279: >> <cr><lf>
19:19:22.280: >> <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=<cr><lf>
19:19:22.280: >> =3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=<cr><lf>
19:19:22.280: >> eva,sans-serif'><cr><lf>
19:19:22.280: >> <p>is this send?</p><cr><lf>
19:19:22.280: >> <cr><lf>
19:19:22.280: >> </body></html><cr><lf>
19:19:22.280: >> <cr><lf>
19:19:22.280: >> --=_572b847be8d8b40e2bb1945b6792fba2--<cr><lf>
19:19:22.281: >> .<cr><lf>
19:19:22.281: << 250 Data received OK.<cr><lf>
19:19:22.281: >> QUIT<cr><lf>
19:19:22.282: << 221 mail.yorktondigital.ca Service closing channel.<cr><lf>
19:19:22.284: --- Connection closed at 15 Mar 2023, 19:19:22.284. ---
19:19:22.284:

Johannes

No error. The 'H' rule terminates the connection directly when the EHLO line is processed, so there is no AUTH attempt.

Hello Rolf,

I see and I know that this is no error of the transaction filter. The transaction filter itself is working correct.

The question what I am asking is, does the box "Successful Auth exempts connection from filtering" applies to the transaction filter or not.
According to the Help, one can argue it does.

Successful AUTH exempts connection from filtering
If you enable SMTP Authentication then you may wish to allow connections that have successfully authenticated themselves to bypass the compliance tests on this page - to do that, check this control. When this control is checked, MercuryS applies a much smaller range of tests to the connection, making it easier for authenticated users to send mail.

That is all what I would like to find out. It seems it,s not, but is that correct ?

Johannes

To understand this it's necessary to have a closer look at how an SMTP transaction works. It's a dialog between the connecting client and the server with a number of specified steps. The first step is the HELO/EHLO greeting. If a connection is terminated already at that stage there will simply never be any AUTH attempt, successful or otherwise.

The 'D' rule allows the possibility to wait for an AUTH attempt before deciding on if the connection should be refused or not.