On 8/15/2024 10:27 AM, Jaroslaw Rafa via mailop wrote:
Well... yes and no 🙂. The famous case of "500 mile email" is always worth
to mention...
https://www.ibiblio.org/harris/500milemail.html
The story is wonderful. I enjoy it every time it surfaces. However it
is also irrelevant to the curre
Dnia 14.08.2024 o godz. 16:30:23 Dave Crocker via mailop pisze:
>
> That is why I was careful not to argue against timeouts, per se, but
> merely not to consider expected distance as a factor.
>
> There are a number of reasons for needing timeouts. And the choice
> of how long or short one shoul
On Wed, Aug 14, 2024 at 06:48:38AM -0700, Dave Crocker via mailop wrote:
> Making a distance-sensitive assumption about traffic behavior is a
> suprisingly bad idea for anything having to do with the Internet. Resources
> and their uses can be -- and often are -- a long way away and using
> conne
Obligatory: https://web.mit.edu/jemorris/humor/500-miles
Scott
On Wednesday, 14/08/2024 at 19:30 Dave Crocker via mailop wrote:
On 8/14/2024 3:17 PM, Slavko via mailop wrote:
Dňa 14. augusta 2024 13:48:38 UTC používateľ Dave Crocker via
mailop [1] napísal:
Making a distance-sen
On 8/14/2024 3:17 PM, Slavko via mailop wrote:
Dňa 14. augusta 2024 13:48:38 UTC používateľ Dave Crocker via
mailop napísal:
Making a distance-sensitive assumption about traffic behavior is a suprisingly
bad idea for anything having to do with the Internet. Resources and their uses
can be
Dňa 14. augusta 2024 13:48:38 UTC používateľ Dave Crocker via mailop
napísal:
>Making a distance-sensitive assumption about traffic behavior is a suprisingly
>bad idea for anything having to do with the Internet. Resources and their
>uses can be -- and often are -- a long way away and using c
On 8/12/2024 1:20 AM, Viktor Dukhovni via mailop wrote:
For SUBMIT, the traffic is presumably from your own users, who are
rarely very far away,
Making a distance-sensitive assumption about traffic behavior is a
suprisingly bad idea for anything having to do with the Internet.
Resources and
It appears that Viktor Dukhovni via mailop said:
>For SUBMIT, the traffic is presumably from your own users, who are
>rarely very far away, and if temporarily on a bad link will try
>again from a better location. So the timeouts on ports 465 and 587
>could be shorter. Whatever your users are unl
Dňa 12. augusta 2024 10:37:25 UTC používateľ Lena--- via mailop
napísal:
>I'm curious: do you get many legitimate connections to tls_on_connect port 465
>(instead of STARTTLS 587)?
All (small number) my real users use 465 port.
>Do you tell your users how to use 587, 465 or both?
I tell them
> From: Slavko
I'm curious: do you get many legitimate connections to tls_on_connect port 465
(instead of STARTTLS 587)?
Do you tell your users how to use 587, 465 or both?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailo
Dňa 12. augusta 2024 8:20:20 UTC používateľ Viktor Dukhovni via mailop
napísal:
>I think it can be rather different for SMTP and SUBMIT services.
Of course, i am talking about MSA, thus 465/tcp only in my case.
>I'm tempted to propose 30s instead of 300s as still reasonable.
It coresponds wit
On Mon, Aug 12, 2024 at 07:34:28AM +, Slavko via mailop wrote:
> Dňa 11. augusta 2024 23:46:43 UTC používateľ Viktor Dukhovni via mailop
> napísal:
>
> >I see some similar traffic (remote disconnects after ~8-30s) on my server:
>
> Please, what would be reasonable TLS handshake timeout now
Dňa 11. augusta 2024 23:46:43 UTC používateľ Viktor Dukhovni via mailop
napísal:
>I see some similar traffic (remote disconnects after ~8-30s) on my server:
Please, what would be reasonable TLS handshake timeout nowadays?
I know, it depends, but anyway i consider 5 min (IMO stanfard SMTP timeo
On Sun, Aug 11, 2024 at 08:12:19PM -0400, Scott Q. wrote:
> In my case the connections were hanging forever. That's why we
> had to get our IDS to kill them after ~5 seconds or they would take up
> a lot of connection slots.
When idle connections don't hang up unilaterally, Postfix times them out
In my case the connections were hanging forever. That's why we
had to get our IDS to kill them after ~5 seconds or they would take up
a lot of connection slots.
Scott
On Sunday, 11/08/2024 at 19:46 Viktor Dukhovni via mailop wrote:
On Sun, Aug 11, 2024 at 05:25:19PM +, Slavko via mailop wr
On Sun, Aug 11, 2024 at 05:25:19PM +, Slavko via mailop wrote:
> Dňa 11. augusta 2024 15:20:50 UTC používateľ "Scott Q. via mailop"
> napísal:
> >I've noticed this maybe 3-4 years ago. Could not tie it to any
> >legitimate customer or application.
>
> Yes, not real users, IPs are mostly fro
Hi,
Dňa 11. augusta 2024 15:20:50 UTC používateľ "Scott Q. via mailop"
napísal:
>I've noticed this maybe 3-4 years ago. Could not tie it to any
>legitimate customer or application.
Yes, not real users, IPs are mostly from US (hi COMCAST), but othervise
from ~60 countries, 219 ASNs... I am more
I've noticed this maybe 3-4 years ago. Could not tie it to any
legitimate customer or application.
We created rules in our IDS to drop these connections after 5 seconds
of inactivity and ban the IP for a week.
Didn't hurt any legitimate users.
Didn't spend much time analyzing it, but I think it
On Sun, 11 Aug 2024 13:44:16 +, Slavko via mailop
wrote:
>It is not big amount, nothing to worry about, i am just curious, if
>someone know what botnet/malware is behind that, as i cannot
>find any details about that. Please is it something known?
There is a wide variety of botnet activity,
Hi Slavko,
I agree with your analysis about what's happening: erroneous
plain-SMTP connect to "immediate SSL" port 465.
> It is not big amount, nothing to worry about, i am just curious, if
> someone know what botnet/malware is behind that, as i cannot
> find any details about that. Please is it
Hi all,
in recent months i see multiple "idle" connection attempts to
465 port. When i did tcpdump on it, i see that client does success
TCP handshake, then nothing is sent over it and finally connection
is cleanly closed by client (FIN after ~10 sec).
I guess that it is plain SMTP connection to
21 matches
Mail list logo
