Hi all,
Any PlanetHoster contact on this list? If you're here, can you reach me in
PM?
One of our IP address is blocked at network level, and through their ticket
system they don't understand that I'm not one of their customer.
Thank you!
Romain
___
We previously were accepting only TLS 1.2 and higher and I was surprised to
see the amount of senders not being able to find common ciphers (I had
mostly encounters with Cisco users), so we decided to also accept TLS 1.0
and 1.1.
But in my opinion, moving the needle upward by not accepting
Dňa 14. 3. o 10:21 Andrew C Aitchison via mailop napísal(a):
Given that TLS encryption in SMTP is hop-by-hop rather than end-to-end,
I am not convinced that this is a significant reduction in security.
Of course, SMTP is hop-by-hop by design, but how important is that
hop-by-hop nowadays?
On 13.03.2024 at 18:25 Kai Bojens via mailop wrote:
> On 2024-03-13 00:09, Andrew C Aitchison via mailop wrote:
>> Given that the advice for SMTP is often to allow tls 1.0 and 1.1,
>> rather than have it revert to unencrypted, this will is something to
>> watch out for.
> TLS 1.0/1.1 have been
On 14.03.2024 at 09:37 Cyril - ImprovMX via mailop wrote:
> We previously were accepting only TLS 1.2 and higher and I was surprised to
> see the amount of senders not being able to find common ciphers (I had mostly
> encounters with Cisco users), so we decided to also accept TLS 1.0 and 1.1.
>
>
> Given that TLS encryption in SMTP is hop-by-hop rather than end-to-end,
> I am not convinced that this is a significant reduction in security.
>
Wouldn't it be because you assume that at some point, the security will be
either non-existent or low (TLS 1.0/1.1 or fallback to unsecured
On 2024-03-14, Marco Moock via mailop wrote:
> sendmail tried to deliver it 20 times during the night - this morning
> I deleted the mail from mqueue.
That's a fairly aggressive retry strategy. If there's something about
that message gmail doesn't like, then retrying that often might be
enough
On Thu, 14 Mar 2024 at 10:09, Marco Moock via mailop wrote:
> Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761:
> to=, delay=09:47:40, xdelay=00:00:03, mailer=esmtp,
> pri=5370980, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.7.28,
> reply=421 4.7.28 Gmail has detected an unusual rate of
Am 14.03.2024 schrieb Stefano Bagnara via mailop :
> On Thu, 14 Mar 2024 at 10:09, Marco Moock via mailop
> wrote:
> > Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761:
> > to=, delay=09:47:40, xdelay=00:00:03, mailer=esmtp,
> > pri=5370980, relay=alt4.gmail-smtp-in.l.google.com.,
On 2024-03-14, Marco Moock via mailop wrote:
> Hello!
>
> Yesterday I replied somebody directly on debian-users (he uses a crappy
> mailer and sends to the author and the mailing list...).
>
> Gmail doesn't like this mail, but rejects it with a tempfail. I've now
> deleted it from mqueue.
>
> Mar
Problem solved, thanks.
Le jeu. 14 mars 2024 à 09:31, Romain a écrit :
> Hi all,
>
> Any PlanetHoster contact on this list? If you're here, can you reach me in
> PM?
> One of our IP address is blocked at network level, and through their
> ticket system they don't understand that I'm not one of
Hello!
Yesterday I replied somebody directly on debian-users (he uses a crappy
mailer and sends to the author and the mailing list...).
Gmail doesn't like this mail, but rejects it with a tempfail. I've now
deleted it from mqueue.
Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761:
to=,
Am 14.03.2024 schrieb Julian Bradfield via mailop :
> They don't reject with 5xx because they're not rejecting that message,
> they are rate-limiting you or the network you're on.
> I get this often, because one user forwards their mail to
> gmail, including all the spam. Google rejects the spam,
Am 14.03.2024 schrieb Cyril - ImprovMX via mailop :
> But in my opinion, moving the needle upward by not accepting
> deprecated versions would force those users to be compliant and
> improve the general security.
Most of them will simply fall back to no encryption. That is the
default setting
On Thu, 14 Mar 2024, Marco Moock via mailop wrote:
Am 14.03.2024 schrieb Cyril - ImprovMX via mailop :
But in my opinion, moving the needle upward by not accepting
deprecated versions would force those users to be compliant and
improve the general security.
Most of them will simply fall
>
> That's precisely the problem: As long as you don't enforce STARTTLS, you
> do not raise the bar or improve security by disabling TLS 1.0 or 1.1,
> because the least secure "protocol", namely no encryption at all, is still
> enabled.
>
Yes! I entirely agree with that!
Le jeu. 14 mars 2024 à
> Of course, in some (most?) cases the target MX host will not be final
> delivery target and will forward message to some MDA, eventually over
> multiple MTAs, but i will consider that as internal thing (secured by
> some way).
> IMO in most cases it is reasonable to forget about hop-by-hop
Am 14.03.2024 schrieb Julian Bradfield via mailop :
> On 2024-03-14, Marco Moock via mailop wrote:
> > sendmail tried to deliver it 20 times during the night - this
> > morning I deleted the mail from mqueue.
>
> That's a fairly aggressive retry strategy.
That is the default in sendmail.
Is
Dňa 14. 3. o 12:03 Marco Moock via mailop napísal(a):
Is there any standard that defines the retry rates or at least a best
practise?
RFC 5321, sect. 4.5.4.1:
In general, the retry interval SHOULD be at least 30 minutes...
--
Slavko
https://www.slavino.sk/
On 13/03/2024 16:43, Bill Cole via mailop wrote:
What is "poor" or "weak" about TLSv1.0 and TLSv1.1 which is relevant
in the context of SMTP, other than their easily-disabled support for
weak ciphers?
On 13.03.24 18:09, Taavi Eomäe via mailop wrote:
If you disable all the weak ciphers
On Thu, 14 Mar 2024, Johann Klasek via mailop wrote:
On Thu, Mar 14, 2024 at 12:03:46PM +0100, Marco Moock via mailop wrote:
Am 14.03.2024 schrieb Julian Bradfield via mailop :
On 2024-03-14, Marco Moock via mailop wrote:
sendmail tried to deliver it 20 times during the night - this
On Thu, Mar 14, 2024 at 12:03:46PM +0100, Marco Moock via mailop wrote:
> Am 14.03.2024 schrieb Julian Bradfield via mailop :
>
> > On 2024-03-14, Marco Moock via mailop wrote:
> > > sendmail tried to deliver it 20 times during the night - this
> > > morning I deleted the mail from mqueue.
> >
On Thu, Mar 14, 2024 at 12:17:39PM +0100, Slavko via mailop wrote:
> D??a 14. 3. o 12:03 Marco Moock via mailop napísal(a):
>
> > Is there any standard that defines the retry rates or at least a best
> > practise?
>
> RFC 5321, sect. 4.5.4.1:
>
> In general, the retry interval SHOULD be at
On 14/03/2024 15:15, Matus UHLAR - fantomas via mailop wrote:
Doesn't this mean that if we disable weak ciphers and exchanges, there
are still some secure options left even with tls 1.0/1.1 ?
You'd be left with one (two-ish), ECDHE+CBC+SHA1+AES128 or AES256. CBC
being the "weakest" part in
Graeme Fowler via mailop wrote:
> On 14 Mar 2024, at 16:53, Michael Grimm via mailop wrote:
>> I am getting listed almost on a daily basis on two IPv6 addresses of mine
>> which happen to be part of OVH's address space (yes, I know).
>
> …you do. So to:
>
>> Is there a way to make that
On Thu, Mar 14, 2024, Marco Moock via mailop wrote:
> Am 14.03.2024 schrieb Julian Bradfield via mailop :
> > On 2024-03-14, Marco Moock via mailop wrote:
> > > sendmail tried to deliver it 20 times during the night - this
> > > morning I deleted the mail from mqueue.
> That is the default in
Hi,
is there someone from Spamhaus reading this list?
I am getting listed almost on a daily basis on two IPv6 addresses of mine which
happen to be part of OVH's address space (yes, I know). Both of my mailservers
are serving a handful users, only (family).
Whenever that happens I am using
On 14 Mar 2024, at 16:53, Michael Grimm via mailop wrote:
> I am getting listed almost on a daily basis on two IPv6 addresses of mine
> which happen to be part of OVH's address space (yes, I know).
…you do. So to:
> Is there a way to make that de-listing more persistent?
Yes. The following
According to Graeme Fowler via mailop :
>As you can see, it’s the entire /64 getting listed in both cases. They’re
>unsavoury neighbourhoods by the look of things.
If you are running a mail server on IPv6, you really do not want to share the
/64 with anyone else.
Everyone I know who does IPv6
Dňa 14. marca 2024 19:15:14 UTC používateľ John Levine via mailop
napísal:
>It would not be hard to use a different address for every message.
More precise, one can get/use new temporary IPv6 address every
5 s (less is ignored on Linux), but IMO with custom kernel even more
often can be
It appears that Slavko via mailop said:
>Dňa 14. marca 2024 19:15:14 UTC používateľ John Levine via mailop
> napísal:
>
>>It would not be hard to use a different address for every message.
>
>More precise, one can get/use new temporary IPv6 address every
>5 s (less is ignored on Linux), but IMO
Am 14.03.2024 um 16:15:11 Uhr schrieb ml+mailop--- via mailop:
> Looks like there is no default (maybe your OS uses some startup
> command with a "default" retry time).
That is the case.
It is a cronjob that runs every 20 minutes.
That applies to Debian and most likely to Ubuntu too.
--
kind
On 3/14/24 10:17, Graeme Fowler via mailop wrote:
On 14 Mar 2024, at 16:53, Michael Grimm via mailop wrote:
I am getting listed almost on a daily basis on two IPv6 addresses of mine which
happen to be part of OVH's address space (yes, I know).
…you do. So to:
Is there a way to make that
On 3/14/24 15:18, Michael Grimm via mailop wrote:
OVH is sharing a /64 subnet among multiple customers since they started their
public cloud project. You are only provided with a single IPv6 address for your
instance. In the years before that, I had had access to an exclusive /64 subnet.
On 3/14/24 13:21, Slavko via mailop wrote:
As the /64 is twice of whole IPv4 mask, plenty "spammers" with
minimal effort, just two/three kernel setting values...
A /64 is actually 4,294,967,296 times the whole IPv4 space, but who's
counting?
--
Jay Hennigan - j...@west.net
Network
Jay Hennigan via mailop wrote:
> On 3/14/24 10:17, Graeme Fowler via mailop wrote:
>> On 14 Mar 2024, at 16:53, Michael Grimm via mailop wrote:
>>> I am getting listed almost on a daily basis on two IPv6 addresses of mine
>>> which happen to be part of OVH's address space (yes, I know).
>>
Would you consider your own /64 or /48 from RIPE?
It's one way of being in control of your own reputation.
--
Alex
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
It appears that Michael Grimm via mailop said:
>> Sharing a /64 among multiple customers doesn't make sense. It's not like OVH
>> is in danger of running out of IPv6 space any time soon.
>
>OVH is sharing a /64 subnet among multiple customers since they started their
>public cloud project. You
38 matches
Mail list logo
