Mailing List Archive

On 06/06/2022 23:18, The Doctor via Exim-users wrote:
> Just going over my spam and I find this IP 195.133.39.99
>
> sending a lot of junk. How can you block such a class C?
>

Multiple possible ways.

One would be a
deny hosts= 195.133.39.0/24
acl verb (assuming you really want the class-C).
You get to choose at what stage of processing you want this.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

It's best to use DNSBL /(DNS Block Lists)/ for this, because then you
don't need to update these yourself: e.g. that particular IP address is
already listed on all three block lists at uceprotect.net.  These work
in the same way as a DNS reverse look-up but instead of returning a
domain name, the result is a value depending on whether or not that
particular DNSBL is listing the originating IP address as a suspected
source of spam.

Use the following in your exim.conf, in the acl_check_rcpt section:

deny    message       = GOODBYE!!! $sender_host_address is in a black
list at $dnslist_domain\n$dnslist_text
        dnslists      = dnsbl-1.uceprotect.net : dnsbl-2.uceprotect.net
: dnsbl-3.uceprotect.net

I also use other DNSBLs, just add the ones you want to use to the
dnslists entry.

On 06/06/2022 23:18, The Doctor via Exim-users wrote:
> Just going over my spam and I find this IP 195.133.39.99
>
> sending a lot of junk. How can you block such a class C?
--
footer
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Me: *"These work in the same way as a DNS reverse look-up but instead of
returning a domain name, the result is a value depending on whether or
not that particular DNSBL is listing the originating IP address as a
suspected source of spam."*

Time I was in bed, asleep... it's not like an rDNS look-up at all...
more like a DNS look-up, but the advice is still good...

And don't block the whole /24 unless you're absolutely certain that you
don't want to accept mail from *any* IP address in that sub-net, e.g.
because of the country of origin.

On 06/06/2022 23:18, The Doctor via Exim-users wrote:
> Just going over my spam and I find this IP 195.133.39.99
>
> sending a lot of junk. How can you block such a class C?

footer
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Mon, Jun 06, 2022 at 11:33:17PM +0100, Jeremy Harris via Exim-users wrote:
> On 06/06/2022 23:18, The Doctor via Exim-users wrote:
> > Just going over my spam and I find this IP 195.133.39.99
> >
> > sending a lot of junk. How can you block such a class C?
> >
>
> Multiple possible ways.
>
> One would be a
> deny hosts= 195.133.39.0/24
> acl verb (assuming you really want the class-C).
> You get to choose at what stage of processing you want this.

I wonder if Reject IP can be class C based.

> --
> Cheers,
> Jeremy
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
27 years of Internet Service since 1/6/1995 ! Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

are those 3 not supposed to resolve in DNS? None of them does in my end..


> deny message       = GOODBYE!!! $sender_host_address is in a black
> list at $dnslist_domain\n$dnslist_text
>         dnslists      = dnsbl-1.uceprotect.net :
> dnsbl-2.uceprotect.net : dnsbl-3.uceprotect.net

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

They only have NS records, because they're name servers(!)... specify
that you want NS records, like this:

dig dnsbl-1.uceprotect.net ns

On 07/06/2022 07:37, Laura Williamson via Exim-users wrote:
> are those 3 not supposed to resolve in DNS? None of them does in my end..
--
footer
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 6/7/22 14:37, Laura Williamson via Exim-users wrote:
> are those 3 not supposed to resolve in DNS? None of them does in my end..

You prefix the IP address in reverse order to the domain. The query is e.g.

99.39.133.195.dnsbl-1.uceprotect.net. IN A

to look up 195.133.39.99

If listed. the A record would be 127.0.0.{1,2,3, ...}

And the meaning of the last octet is locally defined by the specific DNSBL.

You can often get additional details by also getting a TXT record.



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

of course, my mistake.

On 07/06/2022 10:39, R M Crorie via Exim-users wrote:
> They only have NS records, because they're name servers(!)... specify
> that you want NS records, like this:
>
> dig dnsbl-1.uceprotect.net ns
>
> On 07/06/2022 07:37, Laura Williamson via Exim-users wrote:
>> are those 3 not supposed to resolve in DNS? None of them does in my
>> end..

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2022-06-06, The Doctor via Exim-users <exim-users@exim.org> wrote:
> On Mon, Jun 06, 2022 at 11:33:17PM +0100, Jeremy Harris via Exim-users wrote:
>> On 06/06/2022 23:18, The Doctor via Exim-users wrote:
>> > Just going over my spam and I find this IP 195.133.39.99
>> >
>> > sending a lot of junk. How can you block such a class C?
>> >
>>
>> Multiple possible ways.
>>
>> One would be a
>> deny hosts= 195.133.39.0/24
>> acl verb (assuming you really want the class-C).
>> You get to choose at what stage of processing you want this.
>
> I wonder if Reject IP can be class C based.

well, yeah, a network-layer firewall is another solution.
>


--
Jasen.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 08, 2022 at 11:35:15AM +0300, Odhiambo Washington wrote:
> Define this in the global section:
>
> hostlist blocked_hosts = 5.34.207.0/24
>
> Then in acl_smtp_connect:
> drop
> message = You are banned here
> log_message = Blocked host from 5.34.207.0/24 subnet
> ($sender_host_address)
> hosts = +blocked_hosts
>

Still getting

tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078 SYN_RCVD
tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962 SYN_RCVD
tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246 ESTABLISHED
tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268 ESTABLISHED
tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598 ESTABLISHED
tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726 ESTABLISHED
tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444 ESTABLISHED
tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764 ESTABLISHED
tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686 ESTABLISHED
tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412 ESTABLISHED
tcp4 0 0 environmental-so.smtps 5.34.207.49.53302 ESTABLISHED
tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228 ESTABLISHED
tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508 ESTABLISHED
tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664 ESTABLISHED
tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904 ESTABLISHED
tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834 ESTABLISHED
tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432 ESTABLISHED
tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492 ESTABLISHED
tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078 ESTABLISHED
tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406 ESTABLISHED
tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326 ESTABLISHED
tcp4 0 0 unityintegration.smtps 5.34.207.191.29918 ESTABLISHED
tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246 ESTABLISHED
tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136 ESTABLISHED
tcp4 0 0 valpy.com.smtps 5.34.207.153.7492 ESTABLISHED
tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748 ESTABLISHED
tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282 ESTABLISHED
tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794 ESTABLISHED
tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362 ESTABLISHED
tcp4 0 0 valpy.com.smtps 5.34.207.198.50486 ESTABLISHED
tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662 ESTABLISHED
tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002 ESTABLISHED
tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784 ESTABLISHED
tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544 ESTABLISHED
tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030 ESTABLISHED

I am using exim-4.95 from FreeBSD ports.

Etierh the port is in question or the IP block is being faked.


> On Thu, Dec 8, 2022 at 10:31 AM Andreas Metzler via Exim-users <
> exim-users@exim.org> wrote:
>
> > On 2022-12-08 The Doctor via Exim-users <exim-users@exim.org> wrote:
> > > On Wed, Dec 07, 2022 at 04:02:55PM -0700, The Doctor via Exim-users
> > wrote:
> > > > On Wed, Dec 07, 2022 at 04:08:34PM +0000, Jeremy Harris via Exim-users
> > wrote:
> > > > > On 07/12/2022 15:34, The Doctor via Exim-users wrote:
> > > > > > How do you block a whole Class C like
> > > > > > 5.34.207.0/24 using the configuration file?
> > > > >
> > > > > Make a start by reading the manual, about ACLs
> > > > > and hostlists.
> >
> > > > Already did that.
> >
> > > For clarification, here is what I am seeing when I go
> > > netstat -a | egrep smtp
> >
> > > tcp4 0 0 204.209.81.116.smtps 5.34.207.189.11238
> > ESTABLISHED
> > [...]
> >
> > I am missing some sign of "I tried this but it did not work because I
> > failed
> > to understand that specific detail there ...". This looks more like "Phew
> > that is lot to read, let's simply ask."
> >
> > cu Andreas
> > --
> > `What a good friend you are to him, Dr. Maturin. His other friends are
> > so grateful to you.'
> > `I sew his ears on from time to time, sure'
> >
> > --
> > ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> > ## Exim details at http://www.exim.org/
> > ## Please use the Wiki with this list - http://wiki.exim.org/
> >
>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", egrep -v '^$|^.*#' ??\_(???)_/?? :-)

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 08/12/2022 13:26, The Doctor via Exim-users wrote:
> tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078 SYN_RCVD
> tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962 SYN_RCVD
> tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246 ESTABLISHED
> tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268 ESTABLISHED
> tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598 ESTABLISHED
> tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726 ESTABLISHED
> tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444 ESTABLISHED
> tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764 ESTABLISHED
> tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686 ESTABLISHED
> tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412 ESTABLISHED
> tcp4 0 0 environmental-so.smtps 5.34.207.49.53302 ESTABLISHED
> tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228 ESTABLISHED
> tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508 ESTABLISHED
> tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664 ESTABLISHED
> tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904 ESTABLISHED
> tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834 ESTABLISHED
> tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432 ESTABLISHED
> tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492 ESTABLISHED
> tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078 ESTABLISHED
> tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406 ESTABLISHED
> tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326 ESTABLISHED
> tcp4 0 0 unityintegration.smtps 5.34.207.191.29918 ESTABLISHED
> tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246 ESTABLISHED
> tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136 ESTABLISHED
> tcp4 0 0 valpy.com.smtps 5.34.207.153.7492 ESTABLISHED
> tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748 ESTABLISHED
> tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282 ESTABLISHED
> tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794 ESTABLISHED
> tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362 ESTABLISHED
> tcp4 0 0 valpy.com.smtps 5.34.207.198.50486 ESTABLISHED
> tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662 ESTABLISHED
> tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002 ESTABLISHED
> tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784 ESTABLISHED
> tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544 ESTABLISHED
> tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030 ESTABLISHED
>
> I am using exim-4.95 from FreeBSD ports.


Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port 465" there.
If those are hung waiting to complete TLS negotiation, you'd see that.

For those, use the main-config option "host_reject_connection" rather than the
connect ACL - it operates before the TLS startup for TLS-on-connect ports,
while the ACL is run after.


I'm considering changing that, even though it's an incompatible change.
Having the ACL operate before TLS startup (for TLS-on-connect) would align
with the operation for STARTTLS, and possibly cause less surprise.
Anybody want to comment?
--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 08, 2022 at 02:33:01PM +0000, Jeremy Harris via Exim-users wrote:
> On 08/12/2022 13:26, The Doctor via Exim-users wrote:
> > tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078 SYN_RCVD
> > tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962 SYN_RCVD
> > tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246 ESTABLISHED
> > tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268 ESTABLISHED
> > tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598 ESTABLISHED
> > tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726 ESTABLISHED
> > tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444 ESTABLISHED
> > tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764 ESTABLISHED
> > tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686 ESTABLISHED
> > tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412 ESTABLISHED
> > tcp4 0 0 environmental-so.smtps 5.34.207.49.53302 ESTABLISHED
> > tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228 ESTABLISHED
> > tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508 ESTABLISHED
> > tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664 ESTABLISHED
> > tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904 ESTABLISHED
> > tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834 ESTABLISHED
> > tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432 ESTABLISHED
> > tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492 ESTABLISHED
> > tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078 ESTABLISHED
> > tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406 ESTABLISHED
> > tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326 ESTABLISHED
> > tcp4 0 0 unityintegration.smtps 5.34.207.191.29918 ESTABLISHED
> > tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246 ESTABLISHED
> > tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136 ESTABLISHED
> > tcp4 0 0 valpy.com.smtps 5.34.207.153.7492 ESTABLISHED
> > tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748 ESTABLISHED
> > tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282 ESTABLISHED
> > tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794 ESTABLISHED
> > tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362 ESTABLISHED
> > tcp4 0 0 valpy.com.smtps 5.34.207.198.50486 ESTABLISHED
> > tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662 ESTABLISHED
> > tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002 ESTABLISHED
> > tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784 ESTABLISHED
> > tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544 ESTABLISHED
> > tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030 ESTABLISHED
> >
> > I am using exim-4.95 from FreeBSD ports.
>
>
> Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port 465" there.
> If those are hung waiting to complete TLS negotiation, you'd see that.
>
> For those, use the main-config option "host_reject_connection" rather than the
> connect ACL - it operates before the TLS startup for TLS-on-connect ports,
> while the ACL is run after.
>
>
> I'm considering changing that, even though it's an incompatible change.
> Having the ACL operate before TLS startup (for TLS-on-connect) would align
> with the operation for STARTTLS, and possibly cause less surprise.
> Anybody want to comment?

Just reading this.

Tried

host_reject_connection = 5.34.207.*

Still not doing the rejection job.

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 08, 2022 at 10:30:05AM -0700, The Doctor via Exim-users wrote:
> Tried
>
> host_reject_connection = 5.34.207.*
>
> Still not doing the rejection job.

Use CIDR instead of pattern.
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Jeremy Harris via Exim-users schreef op 2022-12-08 15:33:
> On 08/12/2022 13:26, The Doctor via Exim-users wrote:
>> tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078
>> SYN_RCVD
(...)
>> tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030
>> ESTABLISHED
>>
>> I am using exim-4.95 from FreeBSD ports.
>
>
> Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port
> 465" there.
> If those are hung waiting to complete TLS negotiation, you'd see that.
>
> For those, use the main-config option "host_reject_connection" rather
> than the
> connect ACL - it operates before the TLS startup for TLS-on-connect
> ports,
> while the ACL is run after.
>
>
> I'm considering changing that, even though it's an incompatible change.
> Having the ACL operate before TLS startup (for TLS-on-connect) would
> align
> with the operation for STARTTLS, and possibly cause less surprise.
> Anybody want to comment?
> --
> Cheers,
> Jeremy

Port 465 is indeed smtps on FreeBSD.

As a FreeBSD user myself I commit suspicious or caught addresses like
these to a table in PF (either as a single address or a CIDR range) so
they can't reach Exim at all anymore.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 8, 2022 at 8:47 PM The Doctor via Exim-users <
exim-users@exim.org> wrote:

> On Thu, Dec 08, 2022 at 02:33:01PM +0000, Jeremy Harris via Exim-users
> wrote:
> > On 08/12/2022 13:26, The Doctor via Exim-users wrote:
> > > tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078
> SYN_RCVD
> > > tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962
> SYN_RCVD
> > > tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246
> ESTABLISHED
> > > tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268
> ESTABLISHED
> > > tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598
> ESTABLISHED
> > > tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726
> ESTABLISHED
> > > tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444
> ESTABLISHED
> > > tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764
> ESTABLISHED
> > > tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686
> ESTABLISHED
> > > tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412
> ESTABLISHED
> > > tcp4 0 0 environmental-so.smtps 5.34.207.49.53302
> ESTABLISHED
> > > tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228
> ESTABLISHED
> > > tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508
> ESTABLISHED
> > > tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664
> ESTABLISHED
> > > tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904
> ESTABLISHED
> > > tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834
> ESTABLISHED
> > > tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432
> ESTABLISHED
> > > tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492
> ESTABLISHED
> > > tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078
> ESTABLISHED
> > > tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406
> ESTABLISHED
> > > tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326
> ESTABLISHED
> > > tcp4 0 0 unityintegration.smtps 5.34.207.191.29918
> ESTABLISHED
> > > tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246
> ESTABLISHED
> > > tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136
> ESTABLISHED
> > > tcp4 0 0 valpy.com.smtps 5.34.207.153.7492
> ESTABLISHED
> > > tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748
> ESTABLISHED
> > > tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282
> ESTABLISHED
> > > tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794
> ESTABLISHED
> > > tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362
> ESTABLISHED
> > > tcp4 0 0 valpy.com.smtps 5.34.207.198.50486
> ESTABLISHED
> > > tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662
> ESTABLISHED
> > > tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002
> ESTABLISHED
> > > tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784
> ESTABLISHED
> > > tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544
> ESTABLISHED
> > > tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030
> ESTABLISHED
> > >
> > > I am using exim-4.95 from FreeBSD ports.
> >
> >
> > Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port
> 465" there.
> > If those are hung waiting to complete TLS negotiation, you'd see that.
> >
> > For those, use the main-config option "host_reject_connection" rather
> than the
> > connect ACL - it operates before the TLS startup for TLS-on-connect
> ports,
> > while the ACL is run after.
> >
> >
> > I'm considering changing that, even though it's an incompatible change.
> > Having the ACL operate before TLS startup (for TLS-on-connect) would
> align
> > with the operation for STARTTLS, and possibly cause less surprise.
> > Anybody want to comment?
>
> Just reading this.
>
> Tried
>
> host_reject_connection = 5.34.207.*
>
> Still not doing the rejection job.
>

hostlist host_rejects = 5.34.207.0/24
host_reject_connection = +host_rejects

host_reject_connection = +host_reject

root@gw:/usr/home/wash # exim -bh 5.34.207.3

**** SMTP testing session as if from host 5.34.207.3
**** but without any ident (RFC 1413) callback.
**** This is not for real!

>>> host in hosts_connection_nolog? no (option unset)
LOG: SMTP connection from [5.34.207.3]
>>> host in host_lookup? yes (matched "*")
>>> looking up host name for 5.34.207.3
>>> IP address lookup using gethostbyaddr()
>>> IP address lookup failed: h_errno=1
>>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
>>> host in host_reject_connection? yes (matched "+host_rejects")
LOG: refused connection from [5.34.207.3] (host_reject_connection)
554 SMTP service not available
root@gw:/usr/home/wash #



--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(?)_/¯ :-)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via Exim-users wrote:
> On Thu, Dec 8, 2022 at 8:47 PM The Doctor via Exim-users <
> exim-users@exim.org> wrote:
>
> > On Thu, Dec 08, 2022 at 02:33:01PM +0000, Jeremy Harris via Exim-users
> > wrote:
> > > On 08/12/2022 13:26, The Doctor via Exim-users wrote:
> > > > tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078
> > SYN_RCVD
> > > > tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962
> > SYN_RCVD
> > > > tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246
> > ESTABLISHED
> > > > tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598
> > ESTABLISHED
> > > > tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726
> > ESTABLISHED
> > > > tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412
> > ESTABLISHED
> > > > tcp4 0 0 environmental-so.smtps 5.34.207.49.53302
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228
> > ESTABLISHED
> > > > tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664
> > ESTABLISHED
> > > > tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904
> > ESTABLISHED
> > > > tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834
> > ESTABLISHED
> > > > tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432
> > ESTABLISHED
> > > > tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492
> > ESTABLISHED
> > > > tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326
> > ESTABLISHED
> > > > tcp4 0 0 unityintegration.smtps 5.34.207.191.29918
> > ESTABLISHED
> > > > tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246
> > ESTABLISHED
> > > > tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136
> > ESTABLISHED
> > > > tcp4 0 0 valpy.com.smtps 5.34.207.153.7492
> > ESTABLISHED
> > > > tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748
> > ESTABLISHED
> > > > tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362
> > ESTABLISHED
> > > > tcp4 0 0 valpy.com.smtps 5.34.207.198.50486
> > ESTABLISHED
> > > > tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662
> > ESTABLISHED
> > > > tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002
> > ESTABLISHED
> > > > tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784
> > ESTABLISHED
> > > > tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544
> > ESTABLISHED
> > > > tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030
> > ESTABLISHED
> > > >
> > > > I am using exim-4.95 from FreeBSD ports.
> > >
> > >
> > > Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port
> > 465" there.
> > > If those are hung waiting to complete TLS negotiation, you'd see that.
> > >
> > > For those, use the main-config option "host_reject_connection" rather
> > than the
> > > connect ACL - it operates before the TLS startup for TLS-on-connect
> > ports,
> > > while the ACL is run after.
> > >
> > >
> > > I'm considering changing that, even though it's an incompatible change.
> > > Having the ACL operate before TLS startup (for TLS-on-connect) would
> > align
> > > with the operation for STARTTLS, and possibly cause less surprise.
> > > Anybody want to comment?
> >
> > Just reading this.
> >
> > Tried
> >
> > host_reject_connection = 5.34.207.*
> >
> > Still not doing the rejection job.
> >
>
> hostlist host_rejects = 5.34.207.0/24
> host_reject_connection = +host_rejects
>
> host_reject_connection = +host_reject
>
> root@gw:/usr/home/wash # exim -bh 5.34.207.3
>
> **** SMTP testing session as if from host 5.34.207.3
> **** but without any ident (RFC 1413) callback.
> **** This is not for real!
>
> >>> host in hosts_connection_nolog? no (option unset)
> LOG: SMTP connection from [5.34.207.3]
> >>> host in host_lookup? yes (matched "*")
> >>> looking up host name for 5.34.207.3
> >>> IP address lookup using gethostbyaddr()
> >>> IP address lookup failed: h_errno=1
> >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> >>> host in host_reject_connection? yes (matched "+host_rejects")
> LOG: refused connection from [5.34.207.3] (host_reject_connection)
> 554 SMTP service not available
> root@gw:/usr/home/wash #
>
>
>

Still seeing

netstat -a | egrep smtp
tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526 SYN_RCVD
tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872 FIN_WAIT_2
tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546 FIN_WAIT_2




Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users wrote:
> On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via Exim-users wrote:
[...]
> > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > LOG: refused connection from [5.34.207.3] (host_reject_connection)
> > 554 SMTP service not available
> > root@gw:/usr/home/wash #
>
> Still seeing
>
> netstat -a | egrep smtp
> tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526 SYN_RCVD
> tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872 FIN_WAIT_2
> tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546 FIN_WAIT_2

Rejection with status code 554 requires established TCP connection.
Study mainlog to check whether connections are rejected.

However, absense of numerous connections in ESTABLISHED state is a hint
that rejection works.

If you don't want TCP connections, use packet filtering on kernel level
instead of Exim's configuration options.
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 08, 2022 at 10:47:18PM +0300, Evgeniy Berdnikov via Exim-users wrote:
> On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users wrote:
> > On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via Exim-users wrote:
> [...]
> > > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > > LOG: refused connection from [5.34.207.3] (host_reject_connection)
> > > 554 SMTP service not available
> > > root@gw:/usr/home/wash #
> >
> > Still seeing
> >
> > netstat -a | egrep smtp
> > tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526 SYN_RCVD
> > tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872 FIN_WAIT_2
> > tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546 FIN_WAIT_2
>
> Rejection with status code 554 requires established TCP connection.
> Study mainlog to check whether connections are rejected.
>
> However, absense of numerous connections in ESTABLISHED state is a hint
> that rejection works.
>
> If you don't want TCP connections, use packet filtering on kernel level
> instead of Exim's configuration options.

I am surprised that my firewall ACL is not getting this
in a switch!

> --
> Eugene Berdnikov
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 8. decembra 2022 14:33:01 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:

>For those, use the main-config option "host_reject_connection" rather than the
>connect ACL - it operates before the TLS startup for TLS-on-connect ports,
>while the ACL is run after.
>
>I'm considering changing that, even though it's an incompatible change.
>Having the ACL operate before TLS startup (for TLS-on-connect) would align
>with the operation for STARTTLS, and possibly cause less surprise.

>Anybody want to comment?

Yes, i want, if i can, as i know nothing about exim's internals and very
little about TLS, and if my English allow me it ;-)

If i properly understand you, you want to move current "connect" ACL
to be handled before TLS handshake happens. I see that problematic,
not by implementation (i know nothing about it), but with results:

We was talk about this some time ago on IRC, if you remember... You
mentioned, that currently the "host_reject_connection" returns to client
plaintext response... I understand, that this is "historic", but Ii hope that
you will agree, that this is wrong, at least because clients will not
expect plaintext on encrypted connection. Yes, we can consider
those rejected at connect stage as bad and ignore them. But despite
this, we have to respond correctly, as we have to considef misconfigured
clients rather than malicious. Plain response is OK before STARTTLS
was issued, but with TLS-on-connect connection we have either
silently close connection or issue some TLS error. I do not know what
is proper to reject TLS handshake, but i hope that here are people
who know. Or, we can inspire eg. from nginx's solution of rejecting TLS
handshake (BTW, openssl s_client returns it as "alert number 112").

Thus, we have to distinguish connection type (plain/TLS) to choose
appropriate rejection. IMO, better can be to add separate ACL, which
will be called before current connect ACL, but only on TLS-on-connect
ports. Its semantic have to be simmilar to connect ACL, but with defer
either not allowed or treated the same as deny/drop. Simillar with
the message modiffier (ignore/not allow). If i can, i will vote for
allowing both.

Another reason to separate them is, that eg. SNI name and some
other properties are not available before TLS handshake is finished.
Yes, it can be checked latter, but checking at connect stage can
save some possibly not cheap queries in latter ACLs. Checking
SNI in current connect ACL is very effective...

One thing, which is not clear for me, is what you mean by
"align with the operation for STARTTLS", i hope that it is not
what i understand ;-)

And when we are talking about TLS, i consider as useful to allow
encrypted condition in both, the connect and helo ACLs, to one
can distinguish encrypted connections there (now one have to check
eg. $tls_in_cipher variable). Please, can it be added?

regards


--
Slavko
https://www.slavino.sk/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 8, 2022 at 11:38 PM The Doctor via Exim-users <
exim-users@exim.org> wrote:

> On Thu, Dec 08, 2022 at 10:47:18PM +0300, Evgeniy Berdnikov via Exim-users
> wrote:
> > On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users
> wrote:
> > > On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via
> Exim-users wrote:
> > [...]
> > > > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > > > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > > > LOG: refused connection from [5.34.207.3] (host_reject_connection)
> > > > 554 SMTP service not available
> > > > root@gw:/usr/home/wash #
> > >
> > > Still seeing
> > >
> > > netstat -a | egrep smtp
> > > tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526
> SYN_RCVD
> > > tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872
> FIN_WAIT_2
> > > tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546
> FIN_WAIT_2
> >
> > Rejection with status code 554 requires established TCP connection.
> > Study mainlog to check whether connections are rejected.
> >
> > However, absense of numerous connections in ESTABLISHED state is a hint
> > that rejection works.
> >
> > If you don't want TCP connections, use packet filtering on kernel level
> > instead of Exim's configuration options.
>
> I am surprised that my firewall ACL is not getting this
> in a switch!


I shared config snippets that work.
If you wanted to deal with this at the firewall level, you did not need
Exim to do it!

--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(?)_/¯ :-)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 08, 2022 at 11:44:44PM +0300, Odhiambo Washington via Exim-users wrote:
> On Thu, Dec 8, 2022 at 11:38 PM The Doctor via Exim-users <
> exim-users@exim.org> wrote:
>
> > On Thu, Dec 08, 2022 at 10:47:18PM +0300, Evgeniy Berdnikov via Exim-users
> > wrote:
> > > On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users
> > wrote:
> > > > On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via
> > Exim-users wrote:
> > > [...]
> > > > > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > > > > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > > > > LOG: refused connection from [5.34.207.3] (host_reject_connection)
> > > > > 554 SMTP service not available
> > > > > root@gw:/usr/home/wash #
> > > >
> > > > Still seeing
> > > >
> > > > netstat -a | egrep smtp
> > > > tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526
> > SYN_RCVD
> > > > tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872
> > FIN_WAIT_2
> > > > tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546
> > FIN_WAIT_2
> > >
> > > Rejection with status code 554 requires established TCP connection.
> > > Study mainlog to check whether connections are rejected.
> > >
> > > However, absense of numerous connections in ESTABLISHED state is a hint
> > > that rejection works.
> > >
> > > If you don't want TCP connections, use packet filtering on kernel level
> > > instead of Exim's configuration options.
> >
> > I am surprised that my firewall ACL is not getting this
> > in a switch!
>
>
> I shared config snippets that work.
> If you wanted to deal with this at the firewall level, you did not need
> Exim to do it!
>

As I said, the firewall wer not dropping the packets hence the
need to use exim ACL.

By the way,

This looks like a very interesting attack!

Have a look at https://www.nk.ca/~doctor/5.34.207.txt

but be careful!

This file is 113960735 bytes.

> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", egrep -v '^$|^.*#' ??\_(???)_/?? :-)
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Please learn how to write your responses. Either top-post, or post below,
by snipping.

Even without doing anything, my server has been rejecting these IPs because
they are listed on spamhaus.

On Thu, Dec 8, 2022 at 11:58 PM The Doctor <doctor@doctor.nl2k.ab.ca> wrote:

> On Thu, Dec 08, 2022 at 11:44:44PM +0300, Odhiambo Washington via
> Exim-users wrote:
> > On Thu, Dec 8, 2022 at 11:38 PM The Doctor via Exim-users <
> > exim-users@exim.org> wrote:
> >
> > > On Thu, Dec 08, 2022 at 10:47:18PM +0300, Evgeniy Berdnikov via
> Exim-users
> > > wrote:
> > > > On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users
> > > wrote:
> > > > > On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via
> > > Exim-users wrote:
> > > > [...]
> > > > > > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > > > > > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > > > > > LOG: refused connection from [5.34.207.3]
> (host_reject_connection)
> > > > > > 554 SMTP service not available
> > > > > > root@gw:/usr/home/wash #
> > > > >
> > > > > Still seeing
> > > > >
> > > > > netstat -a | egrep smtp
> > > > > tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526
> > > SYN_RCVD
> > > > > tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872
> > > FIN_WAIT_2
> > > > > tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546
> > > FIN_WAIT_2
> > > >
> > > > Rejection with status code 554 requires established TCP connection.
> > > > Study mainlog to check whether connections are rejected.
> > > >
> > > > However, absense of numerous connections in ESTABLISHED state is a
> hint
> > > > that rejection works.
> > > >
> > > > If you don't want TCP connections, use packet filtering on kernel
> level
> > > > instead of Exim's configuration options.
> > >
> > > I am surprised that my firewall ACL is not getting this
> > > in a switch!
> >
> >
> > I shared config snippets that work.
> > If you wanted to deal with this at the firewall level, you did not need
> > Exim to do it!
> >
>
> As I said, the firewall wer not dropping the packets hence the
> need to use exim ACL.
>
> By the way,
>
> This looks like a very interesting attack!
>
> Have a look at https://www.nk.ca/~doctor/5.34.207.txt
>
> but be careful!
>
> This file is 113960735 bytes.
>
> > --
> > Best regards,
> > Odhiambo WASHINGTON,
> > Nairobi,KE
> > +254 7 3200 0004/+254 7 2274 3223
> > "Oh, the cruft.", egrep -v '^$|^.*#' ??\_(???)_/?? :-)
> > --
> > ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> > ## Exim details at http://www.exim.org/
> > ## Please use the Wiki with this list - http://wiki.exim.org/
>
> --
> Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
> Yahweh, King & country!Never Satan President Republic!Beware AntiChrist
> rising!
> Look at Psalms 14 and 53 on Atheism
> https://www.empire.kred/ROOTNK?t=94a1f39b
> Happy Christmas 2022 and Merry New Year 2023 Beware
> https://mindspring.com
>


--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(?)_/¯ :-)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 08/12/2022 20:42, Slavko via Exim-users wrote:
> D?a 8. decembra 2022 14:33:01 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:
>
>> For those, use the main-config option "host_reject_connection" rather than the
>> connect ACL - it operates before the TLS startup for TLS-on-connect ports,
>> while the ACL is run after.
>>
>> I'm considering changing that, even though it's an incompatible change.
>> Having the ACL operate before TLS startup (for TLS-on-connect) would align
>> with the operation for STARTTLS, and possibly cause less surprise.
>
>> Anybody want to comment?
>
> Yes, i want, if i can, as i know nothing about exim's internals and very
> little about TLS, and if my English allow me it ;-)
>
> If i properly understand you, you want to move current "connect" ACL
> to be handled before TLS handshake happens. I see that problematic,
> not by implementation (i know nothing about it), but with results:
>
> We was talk about this some time ago on IRC, if you remember... You
> mentioned, that currently the "host_reject_connection" returns to client
> plaintext response... I understand, that this is "historic", but Ii hope that
> you will agree, that this is wrong, at least because clients will not
> expect plaintext on encrypted connection.

That is arguably a matter of semantics and expectations. At the TCP-and-TLS
level, a TLS startup has not bee done yet (so responding with an encrypted
SMTP failure response isn't possible, and doing a TLS startup just in
order to do so is precisely what we're wanting to avoid. At the SMTP level
it could be argued that connection has not yet completed, so an SMTP response
of any kind is bad. At the application-client level, trying to make a
TLS-on-connect connection and get an (encrypted) banner... it won't be managing
to make the TLS-level connection whether we put anything on the wire
(in plaintext) or not.

We could just drop the connection at the TCP level, silently; that wouldn't
be hard to code. I don't think it'd make any difference to a client
that didn't have a human peering at a packet capture of the connection
attempt.

> Yes, we can consider
> those rejected at connect stage as bad and ignore them. But despite
> this, we have to respond correctly, as we have to considef misconfigured
> clients rather than malicious. Plain response is OK before STARTTLS
> was issued, but with TLS-on-connect connection we have either
> silently close connection or issue some TLS error. I do not know what
> is proper to reject TLS handshake, but i hope that here are people
> who know. Or, we can inspire eg. from nginx's solution of rejecting TLS
> handshake (BTW, openssl s_client returns it as "alert number 112").

"unrecognized name" ?
per https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-6
at least. That should be used for an SNI mismatch; I don't see that it should be
used for an administrative denial

[.
49 access_denied sounds nice, but it's apparently, per RFC 8446,
for "A valid certificate or PSK was received, but when
access control was applied, the sender decided not to proceed with
negotiation." - and we've not even assessed any such validity.
71 insufficient_security might work
]

But sending anything complex enough to need the TLS library sounds like
too much hard work. I don't think either supported library provides
a simple way of "start the handshake and intentionally cancel it".

>
> Thus, we have to distinguish connection type (plain/TLS) to choose
> appropriate rejection. IMO, better can be to add separate ACL, which
> will be called before current connect ACL, but only on TLS-on-connect
> ports[...]
> Another reason to separate them is, that eg. SNI name and some
> other properties are not available before TLS handshake is finished.

Not so. It's available early and can be used to select the server cert.
So, selecting a nonexistent cert depending on SNI can be done
and will result in no TLS connection.

What other properties?

> One thing, which is not clear for me, is what you mean by
> "align with the operation for STARTTLS", i hope that it is not
> what i understand ;-)

Since you didn't say, I can't tell...

By "align" I mean "operates before TLS startup".

> And when we are talking about TLS, i consider as useful to allow
> encrypted condition in both, the connect and helo ACLs, to one
> can distinguish encrypted connections there (now one have to check
> eg. $tls_in_cipher variable). Please, can it be added?

There is an "encrypted=" ACL condition. Or you can check $tls_in_cipher,
as you said - it's fully equivalent.
--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Dec 08, 2022 at 08:42:46PM +0000, Slavko via Exim-users wrote:
> D??a 8. decembra 2022 14:33:01 UTC pou????vate?? Jeremy Harris via Exim-users <exim-users@exim.org> nap??sal:
>
> >For those, use the main-config option "host_reject_connection" rather than the
> >connect ACL - it operates before the TLS startup for TLS-on-connect ports,
> >while the ACL is run after.
> >
> >I'm considering changing that, even though it's an incompatible change.
> >Having the ACL operate before TLS startup (for TLS-on-connect) would align
> >with the operation for STARTTLS, and possibly cause less surprise.
>
> >Anybody want to comment?
>
> Yes, i want, if i can, as i know nothing about exim's internals and very
> little about TLS, and if my English allow me it ;-)
>
> If i properly understand you, you want to move current "connect" ACL
> to be handled before TLS handshake happens. I see that problematic,
> not by implementation (i know nothing about it), but with results:
>
> We was talk about this some time ago on IRC, if you remember... You
> mentioned, that currently the "host_reject_connection" returns to client
> plaintext response... I understand, that this is "historic", but Ii hope that
> you will agree, that this is wrong, at least because clients will not
> expect plaintext on encrypted connection. Yes, we can consider
> those rejected at connect stage as bad and ignore them. But despite
> this, we have to respond correctly, as we have to considef misconfigured
> clients rather than malicious. Plain response is OK before STARTTLS
> was issued, but with TLS-on-connect connection we have either
> silently close connection or issue some TLS error. I do not know what
> is proper to reject TLS handshake, but i hope that here are people
> who know. Or, we can inspire eg. from nginx's solution of rejecting TLS
> handshake (BTW, openssl s_client returns it as "alert number 112").
>
> Thus, we have to distinguish connection type (plain/TLS) to choose
> appropriate rejection. IMO, better can be to add separate ACL, which
> will be called before current connect ACL, but only on TLS-on-connect
> ports. Its semantic have to be simmilar to connect ACL, but with defer
> either not allowed or treated the same as deny/drop. Simillar with
> the message modiffier (ignore/not allow). If i can, i will vote for
> allowing both.
>
> Another reason to separate them is, that eg. SNI name and some
> other properties are not available before TLS handshake is finished.
> Yes, it can be checked latter, but checking at connect stage can
> save some possibly not cheap queries in latter ACLs. Checking
> SNI in current connect ACL is very effective...
>
> One thing, which is not clear for me, is what you mean by
> "align with the operation for STARTTLS", i hope that it is not
> what i understand ;-)
>
> And when we are talking about TLS, i consider as useful to allow
> encrypted condition in both, the connect and helo ACLs, to one
> can distinguish encrypted connections there (now one have to check
> eg. $tls_in_cipher variable). Please, can it be added?
>
> regards
>

Looks like a fix for 4.97 .

I still wonder why the FReeBSD porters never went up to 4.96?

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Fri, Dec 9, 2022 at 9:47 AM The Doctor via Exim-users <
exim-users@exim.org> wrote:

> On Thu, Dec 08, 2022 at 08:42:46PM +0000, Slavko via Exim-users wrote:
> > D??a 8. decembra 2022 14:33:01 UTC pou????vate?? Jeremy Harris via
> Exim-users <exim-users@exim.org> nap??sal:
> >
> > >For those, use the main-config option "host_reject_connection" rather
> than the
> > >connect ACL - it operates before the TLS startup for TLS-on-connect
> ports,
> > >while the ACL is run after.
> > >
> > >I'm considering changing that, even though it's an incompatible change.
> > >Having the ACL operate before TLS startup (for TLS-on-connect) would
> align
> > >with the operation for STARTTLS, and possibly cause less surprise.
> >
> > >Anybody want to comment?
> >
> > Yes, i want, if i can, as i know nothing about exim's internals and very
> > little about TLS, and if my English allow me it ;-)
> >
> > If i properly understand you, you want to move current "connect" ACL
> > to be handled before TLS handshake happens. I see that problematic,
> > not by implementation (i know nothing about it), but with results:
> >
> > We was talk about this some time ago on IRC, if you remember... You
> > mentioned, that currently the "host_reject_connection" returns to client
> > plaintext response... I understand, that this is "historic", but Ii hope
> that
> > you will agree, that this is wrong, at least because clients will not
> > expect plaintext on encrypted connection. Yes, we can consider
> > those rejected at connect stage as bad and ignore them. But despite
> > this, we have to respond correctly, as we have to considef misconfigured
> > clients rather than malicious. Plain response is OK before STARTTLS
> > was issued, but with TLS-on-connect connection we have either
> > silently close connection or issue some TLS error. I do not know what
> > is proper to reject TLS handshake, but i hope that here are people
> > who know. Or, we can inspire eg. from nginx's solution of rejecting TLS
> > handshake (BTW, openssl s_client returns it as "alert number 112").
> >
> > Thus, we have to distinguish connection type (plain/TLS) to choose
> > appropriate rejection. IMO, better can be to add separate ACL, which
> > will be called before current connect ACL, but only on TLS-on-connect
> > ports. Its semantic have to be simmilar to connect ACL, but with defer
> > either not allowed or treated the same as deny/drop. Simillar with
> > the message modiffier (ignore/not allow). If i can, i will vote for
> > allowing both.
> >
> > Another reason to separate them is, that eg. SNI name and some
> > other properties are not available before TLS handshake is finished.
> > Yes, it can be checked latter, but checking at connect stage can
> > save some possibly not cheap queries in latter ACLs. Checking
> > SNI in current connect ACL is very effective...
> >
> > One thing, which is not clear for me, is what you mean by
> > "align with the operation for STARTTLS", i hope that it is not
> > what i understand ;-)
> >
> > And when we are talking about TLS, i consider as useful to allow
> > encrypted condition in both, the connect and helo ACLs, to one
> > can distinguish encrypted connections there (now one have to check
> > eg. $tls_in_cipher variable). Please, can it be added?
> >
> > regards
> >
>
> Looks like a fix for 4.97 .
>
> I still wonder why the FReeBSD porters never went up to 4.96?
>

You can always do a manual compile/ install. That is what I do.


--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(?)_/¯ :-)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

I am sorry for delay...

D?a 8. decembra 2022 21:37:32 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:

>We could just drop the connection at the TCP level, silently; that wouldn't
>be hard to code. I don't think it'd make any difference to a client
>that didn't have a human peering at a packet capture of the connection
>attempt.

Drop silently is what i suggested and have "human" on remote side is
IMO expected on SubmissionS connections.

>"unrecognized name" ?

Yes, perhaps not good example, as that was TLS handshake rejected
from name base virtual server, there are other names which responds
to HTTPS in it... I have not opposite example -- rejecting by default, but
accepting on some names.

>71 insufficient_security might work

I cannnot comment, my knowledge is not enough, but looks OK.

>But sending anything complex enough to need the TLS library sounds like
>too much hard work. I don't think either supported library provides
>a simple way of "start the handshake and intentionally cancel it".

While i do not know how it is implemented in library, i will guess that
there is something, at least in OpenSSL. I remember that i read some
bugreport in nginx with that TLS handshake rejection and there was
mentioned some problem inside library too (both solved now), but i
never really wrote in C, nor directly used OpenSSL lib, thus i didn't read
details carefuly. I have no links noted...

>Not so. It's available early and can be used to select the server cert.

AFAIK SNI is part of TLS Client Hello. For now i understand that we
are talking about rejection before TLS handshake starts, thus no
SNI is available (nor other TLS related variables). Are you talking
about rejection in "middle" of TLS handshake or even after it is
finished?

>> One thing, which is not clear for me, is what you mean by
>> "align with the operation for STARTTLS", i hope that it is not
>> what i understand ;-)
>
>By "align" I mean "operates before TLS startup".

I was understanding that as common ACL for both, now it is clear.

>There is an "encrypted=" ACL condition. Or you can check $tls_in_cipher,
>as you said - it's fully equivalent.

When i recently tried to use "encrypted=" ACL condition in helo ACL
i got error, thus while fully equivalent, they are not interchangable
in all related ACLs and it was not documented.

regards


--
Slavko
https://www.slavino.sk/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 10/12/2022 16:27, Slavko via Exim-users wrote:
> D?a 8. decembra 2022 21:37:32 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:
>
>> We could just drop the connection at the TCP level, silently; that wouldn't
>> be hard to code. I don't think it'd make any difference to a client
>> that didn't have a human peering at a packet capture of the connection
>> attempt.
>
> Drop silently is what i suggested

I've gone with "silently": 4243a209fd94



[SNI]
>> Not so. It's available early and can be used to select the server cert.
>
> AFAIK SNI is part of TLS Client Hello. For now i understand that we
> are talking about rejection before TLS handshake starts, thus no
> SNI is available (nor other TLS related variables). Are you talking
> about rejection in "middle" of TLS handshake or even after it is
> finished?

Yes, for SNI it have to be after the first bit of the TLS startup
exchange.


>> There is an "encrypted=" ACL condition. Or you can check $tls_in_cipher,
>> as you said - it's fully equivalent.
>
> When i recently tried to use "encrypted=" ACL condition in helo ACL
> i got error, thus while fully equivalent, they are not interchangable
> in all related ACLs and it was not documented.
Details on that, please?
--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 10. decembra 2022 17:01:52 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:

>Yes, for SNI it have to be after the first bit of the TLS startup
>exchange.

Now i am confused. I read that commit (docs changes), but it
is not clear for me, will have $tls_in_* variables values in
connect ACL? I guess that no, but if so, please can you mention
that somewhere?

I am using the SNI variable in connect ACL, to filter rogue
connections eg. with my MX name or no SNI at all (465). They
are not often, but happens and when SNI will be not set, all
my clients will be filled to firewall...

Also, you previously mention using not valid certificate for wrong
SNI name to get TLS failed (or so). It is not clear for me if you mean
certificate with not valid name or file which is not certificate (eg.
/dev/null). IMO bruteforcers doesn't care about valid certificate,
thus using not valid certificate will confuse only legitime clients.

When i did mistake in cert/key lookup expansion some time, exim
log it loudly (but it was nonexistent file)... If i rember properly, docs
exatly mentions to use "default" certificate/key for no/invalid SNI...

Please, can you elaborate more what you mean by that? + some
example if appropriate.

>> When i recently tried to use "encrypted=" ACL condition in helo ACL
>> i got error, thus while fully equivalent, they are not interchangable
>> in all related ACLs and it was not documented.
>Details on that, please?

With exim 4.94.2 i can use "encrypted=" ACL condition in connect ACL,
but not in helo ACL, tested with -bh:

>>> using ACL "acl_check_helo"
>>> processing "warn" (/var/lib/exim4/config.autogenerated 1065)
>>> check !encrypted = *
>>> warn: condition test error in ACL "acl_check_helo"

Result is 451 (Temporary local problem - please try later) with log:

LOG: ... temporarily rejected EHLO or HELO ...:
cannot test encrypted condition in EHLO or HELO ACL

regards

--
Slavko
https://www.slavino.sk/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 10/12/2022 20:13, Slavko via Exim-users wrote:
> D?a 10. decembra 2022 17:01:52 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:
>
>> Yes, for SNI it have to be after the first bit of the TLS startup
>> exchange.
>
> Now i am confused. I read that commit (docs changes), but it
> is not clear for me, will have $tls_in_* variables values in
> connect ACL? I guess that no, but if so, please can you mention
> that somewhere?

No; since the TLS startup has not been done, the TLS client Hello
has not yet ben seen by the TLS library and Exim has had no
opportunity to fill in $tls_in_*

> I am using the SNI variable in connect ACL, to filter rogue
> connections eg. with my MX name or no SNI at all (465).

Doing that never would have worked for non- TLS-on-connect,
and now it won't work ever. Your 465 operations will need
rethinking in this respect.


> Also, you previously mention using not valid certificate for wrong
> SNI name to get TLS failed (or so). It is not clear for me if you mean
> certificate with not valid name or file which is not certificate (eg.
> /dev/null).

The latter. Logged error messsages become a little abstruse, but
it does what's needed (the TLS startup fails).


> Please, can you elaborate more what you mean by that? + some
> example if appropriate.

tls_certificate = ${if eq {$tls_in_sni}{disliked_sni} {/dev/null} {my_good_certfile}}


>>> When i recently tried to use "encrypted=" ACL condition in helo ACL
>>> i got error, thus while fully equivalent, they are not interchangable
>>> in all related ACLs and it was not documented.

> LOG: ... temporarily rejected EHLO or HELO ...:
> cannot test encrypted condition in EHLO or HELO ACL

Ah, ok. There has always been a specific lockout against trying
to use that ACL condition in that circumstance, because it make no
sense for STARTTLS. And TLS-on-connect wasn't thought of.

Sorry to have misled you.

--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 11. decembra 2022 17:15:10 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:

>> I am using the SNI variable in connect ACL, to filter rogue
>> connections eg. with my MX name or no SNI at all (465).
>
>Doing that never would have worked for non- TLS-on-connect,
>and now it won't work ever. Your 465 operations will need
>rethinking in this respect.

I am aware of that and i was talking about 465 connections
of course. (BTW, i don't expose 587 MSA's port to public at all for
multiple years)

>> Also, you previously mention using not valid certificate for wrong
>> SNI name to get TLS failed (or so). It is not clear for me if you mean
>> certificate with not valid name or file which is not certificate (eg.
>> /dev/null).
>
>The latter. Logged error messsages become a little abstruse, but
>it does what's needed (the TLS startup fails).

Thanks, i will play with this and return to it (if needed) in future.

>> LOG: ... temporarily rejected EHLO or HELO ...:
>> cannot test encrypted condition in EHLO or HELO ACL
>
>Ah, ok. There has always been a specific lockout against trying
>to use that ACL condition in that circumstance, because it make no
>sense for STARTTLS. And TLS-on-connect wasn't thought of.

In case of STARTTLS, it makes no sense for me in connect ACL,
but there it works. In helo ACL it makes sense for me, eg. to skip
checks for second EHLO (after STARTTLS), especially with the
same HELO (EHLO) name as before. What i miss here?

>Sorry to have misled you.

No problem, at least i test, that it still works as i described ;-)

regards


--
Slavko
https://www.slavino.sk/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 11/12/2022 18:34, Slavko via Exim-users wrote:
> In case of STARTTLS, it makes no sense for me in connect ACL,
> but there it works. In helo ACL it makes sense for me, eg. to skip
> checks for second EHLO (after STARTTLS), especially with the
> same HELO (EHLO) name as before. What i miss here?

Fair point. On the history I have available, the HELO acl lockout
for the encrypted condition was added between version 4.14 and 4.20,
which is also when acl_smtp_helo arrived (from the ChangeLog file,
there do not have been any intermediate versions released).

The latter was in April 2003. There isn't any commentary for the
rationale for the lockout; the docs do say "called for HELO or EHLO"
for the ACL. Perhaps just the EHLO after STARTTLS was forgotten.

I'm tempted to remove the restriction.
--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 12. decembra 2022 23:25:53 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:

>The latter was in April 2003. There isn't any commentary for the
>rationale for the lockout; the docs do say "called for HELO or EHLO"
>for the ACL. Perhaps just the EHLO after STARTTLS was forgotten.

Perhaps, i didn't work with email in that time, but i will guess, that
STARTTLS was not as common in that time as now (as in many
other protocols).

>I'm tempted to remove the restriction.

I will appreciate this, thanks

regards


--
Slavko
https://www.slavino.sk/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Tue, Dec 13, 2022 at 05:06:51PM +0000, Slavko via Exim-users wrote:
> D??a 12. decembra 2022 23:25:53 UTC pou????vate?? Jeremy Harris via Exim-users <exim-users@exim.org> nap??sal:
>
> >The latter was in April 2003. There isn't any commentary for the
> >rationale for the lockout; the docs do say "called for HELO or EHLO"
> >for the ACL. Perhaps just the EHLO after STARTTLS was forgotten.
>
> Perhaps, i didn't work with email in that time, but i will guess, that
> STARTTLS was not as common in that time as now (as in many
> other protocols).
>
> >I'm tempted to remove the restriction.
>
> I will appreciate this, thanks
>
> regards
>

For 4.97 .

>
> --
> Slavko
> https://www.slavino.sk/
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Still having problems with

/var/log/exim/in_rejectlog:2023-01-18 14:27:01.484 [97258] refused connection from [46.148.40.108]:61402 I=[204.209.81.246]:465 (host_reject_connection)

THere are still coming and not being dropped in a timely manner.

can these packets be dropped in less than 0.01 ms?

Legit e-mail is not getting through and costumers are complaining.


You can check https://www.nk.ca/eximstats.html OR

https://www.nk.ca/eximstats-YYYY-MM-DD.html

for more information.

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Birthdate: 29 Jan 1969 Redhill, Surrey, England Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Block at the firewall before they reach the server.

On Thu, Jan 19, 2023, 00:33 The Doctor <doctor@doctor.nl2k.ab.ca> wrote:

> Still having problems with
>
> /var/log/exim/in_rejectlog:2023-01-18 14:27:01.484 [97258] refused
> connection from [46.148.40.108]:61402 I=[204.209.81.246]:465
> (host_reject_connection)
>
> THere are still coming and not being dropped in a timely manner.
>
> can these packets be dropped in less than 0.01 ms?
>
> Legit e-mail is not getting through and costumers are complaining.
>
>
> You can check https://www.nk.ca/eximstats.html OR
>
> https://www.nk.ca/eximstats-YYYY-MM-DD.html
>
> for more information.
>
> --
> Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
> Yahweh, King & country!Never Satan President Republic!Beware AntiChrist
> rising!
> Look at Psalms 14 and 53 on Atheism
> https://www.empire.kred/ROOTNK?t=94a1f39b
> Birthdate: 29 Jan 1969 Redhill, Surrey, England Beware
> https://mindspring.com
>
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Jan 19, 2023 at 12:36:38AM +0300, Odhiambo Washington via Exim-users wrote:
> Block at the firewall before they reach the server.
>
> On Thu, Jan 19, 2023, 00:33 The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
>
> > Still having problems with
> >
> > /var/log/exim/in_rejectlog:2023-01-18 14:27:01.484 [97258] refused
> > connection from [46.148.40.108]:61402 I=[204.209.81.246]:465
> > (host_reject_connection)
> >
> > THere are still coming and not being dropped in a timely manner.
> >
> > can these packets be dropped in less than 0.01 ms?
> >
> > Legit e-mail is not getting through and costumers are complaining.
> >
> >
> > You can check https://www.nk.ca/eximstats.html OR
> >
> > https://www.nk.ca/eximstats-YYYY-MM-DD.html
> >
> > for more information.
> >

Ateempted but not happening. I wonder if the IPs are being faked.

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Birthdate: 29 Jan 1969 Redhill, Surrey, England Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Wed, 18 Jan 2023, The Doctor via Exim-users wrote:

>> On Thu, Jan 19, 2023, 00:33 The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
>>
>>> Still having problems with
>>>
>>> /var/log/exim/in_rejectlog:2023-01-18 14:27:01.484 [97258] refused
>>> connection from [46.148.40.108]:61402 I=[204.209.81.246]:465
>>> (host_reject_connection)
>>>
>>> THere are still coming and not being dropped in a timely manner.
>>>
>>> can these packets be dropped in less than 0.01 ms?
>>>
>>> Legit e-mail is not getting through and costumers are complaining.
>
>> On Thu, Jan 19, 2023 at 12:36:38AM +0300, Odhiambo Washington via Exim-users wrote:
>> Block at the firewall before they reach the server.
>>
> Ateempted but not happening. I wonder if the IPs are being faked.

I don't think faked packets would get through the firewall if you are
blocking the faked IP address.

The logs indicate that the attacker is connecting to port 465.
Are you blocking that as well as port 25 ?

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Jan 19, 2023 at 08:44:30AM +0000, Andrew C Aitchison via Exim-users wrote:
> On Wed, 18 Jan 2023, The Doctor via Exim-users wrote:
>
> >> On Thu, Jan 19, 2023, 00:33 The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
> >>
> >>> Still having problems with
> >>>
> >>> /var/log/exim/in_rejectlog:2023-01-18 14:27:01.484 [97258] refused
> >>> connection from [46.148.40.108]:61402 I=[204.209.81.246]:465
> >>> (host_reject_connection)
> >>>
> >>> THere are still coming and not being dropped in a timely manner.
> >>>
> >>> can these packets be dropped in less than 0.01 ms?
> >>>
> >>> Legit e-mail is not getting through and costumers are complaining.
> >
> >> On Thu, Jan 19, 2023 at 12:36:38AM +0300, Odhiambo Washington via Exim-users wrote:
> >> Block at the firewall before they reach the server.
> >>
> > Ateempted but not happening. I wonder if the IPs are being faked.
>
> I don't think faked packets would get through the firewall if you are
> blocking the faked IP address.
>
> The logs indicate that the attacker is connecting to port 465.
> Are you blocking that as well as port 25 ?
>

I cannot block port 25 if I want mail from the outside world to get it.

> --
> Andrew C. Aitchison Kendal, UK
> andrew@aitchison.me.uk
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Birthdate: 29 Jan 1969 Redhill, Surrey, England Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, 19 Jan 2023, The Doctor wrote:

> On Thu, Jan 19, 2023 at 08:44:30AM +0000, Andrew C Aitchison via Exim-users wrote:
>> On Wed, 18 Jan 2023, The Doctor via Exim-users wrote:
>>
>>>> On Thu, Jan 19, 2023, 00:33 The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
>>>>
>>>>> Still having problems with
>>>>>
>>>>> /var/log/exim/in_rejectlog:2023-01-18 14:27:01.484 [97258] refused
>>>>> connection from [46.148.40.108]:61402 I=[204.209.81.246]:465
>>>>> (host_reject_connection)
>>>>>
>>>>> THere are still coming and not being dropped in a timely manner.
>>>>>
>>>>> can these packets be dropped in less than 0.01 ms?
>>>>>
>>>>> Legit e-mail is not getting through and costumers are complaining.
>>>
>>>> On Thu, Jan 19, 2023 at 12:36:38AM +0300, Odhiambo Washington via Exim-users wrote:
>>>> Block at the firewall before they reach the server.
>>>>
>>> Ateempted but not happening. I wonder if the IPs are being faked.
>>
>> I don't think faked packets would get through the firewall if you are
>> blocking the faked IP address.
>>
>> The logs indicate that the attacker is connecting to port 465.
>> Are you blocking that as well as port 25 ?
>>
> I cannot block port 25 if I want mail from the outside world to get it.

I assumed that you were blocking the pair
(src ip 46.148.40.108, target port 25)
and was checking that you are also blocking
(src ip 46.148.40.108, target port 465)

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Thu, Jan 19, 2023 at 11:57:04AM +0000, Andrew C Aitchison via Exim-users wrote:
> On Thu, 19 Jan 2023, The Doctor wrote:
>
> > On Thu, Jan 19, 2023 at 08:44:30AM +0000, Andrew C Aitchison via Exim-users wrote:
> >> On Wed, 18 Jan 2023, The Doctor via Exim-users wrote:
> >>
> >>>> On Thu, Jan 19, 2023, 00:33 The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
> >>>>
> >>>>> Still having problems with
> >>>>>
> >>>>> /var/log/exim/in_rejectlog:2023-01-18 14:27:01.484 [97258] refused
> >>>>> connection from [46.148.40.108]:61402 I=[204.209.81.246]:465
> >>>>> (host_reject_connection)
> >>>>>
> >>>>> THere are still coming and not being dropped in a timely manner.
> >>>>>
> >>>>> can these packets be dropped in less than 0.01 ms?
> >>>>>
> >>>>> Legit e-mail is not getting through and costumers are complaining.
> >>>
> >>>> On Thu, Jan 19, 2023 at 12:36:38AM +0300, Odhiambo Washington via Exim-users wrote:
> >>>> Block at the firewall before they reach the server.
> >>>>
> >>> Ateempted but not happening. I wonder if the IPs are being faked.
> >>
> >> I don't think faked packets would get through the firewall if you are
> >> blocking the faked IP address.
> >>
> >> The logs indicate that the attacker is connecting to port 465.
> >> Are you blocking that as well as port 25 ?
> >>
> > I cannot block port 25 if I want mail from the outside world to get it.
>
> I assumed that you were blocking the pair
> (src ip 46.148.40.108, target port 25)
> and was checking that you are also blocking
> (src ip 46.148.40.108, target port 465)
>

Could this cause a 601 error?

> --
> Andrew C. Aitchison Kendal, UK
> andrew@aitchison.me.uk
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Birthdate: 29 Jan 1969 Redhill, Surrey, England Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 19/01/2023 17:32, The Doctor via Exim-users wrote:
>> I assumed that you were blocking the pair
>> (src ip 46.148.40.108, target port 25)
>> and was checking that you are also blocking
>> (src ip 46.148.40.108, target port 465)
>>
> Could this cause a 601 error?

Possibly a typo? SMTP does not define any 6xx error code.

Also, irrelevant. Blocking done by a firewall would be
stopping TCP-level connection, so you won't get any SMTP
communication at all. How a client reports that is up to it.

--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/