Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[John Levine via 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 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.
>
>
>But that isn't the point of my initial post: Spamhaus is blocking the /64 
>subnet my address is part of. Fair enough. 
>
>*But* on the other hand they are offering an web-based de-listing service 
>without human interference. Good. After successful delisting, that particular 
>IPv6 address
>becomes immediately de-listed. Fine.
>
>That tells me, that they must have a setup where individual IPv6 of a blocked 
>/64 subnet become whitelisted. *That* worked in the past for a very long time. 
>Only
>recently the whitelisting is of a very short time frame.

No, it means that they will let people delist a few mistakes, but if the /64 
keeps being
listed I think you will find that the self removal goes away.

The solution is to find a competent hosting company that will provide
your own /64. As I keep saying, sometimes when you pick a cheap
option, you get what you pay for.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Alexander Huynh via mailop]

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

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Jay Hennigan via mailop]

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 Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Jay Hennigan via mailop]

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.


This is very bad practice on OVH's part. Why are they doing this? Are 
they afraid of running out of IPv6 addresses?



But that isn't the point of my initial post: Spamhaus is blocking the /64 
subnet my address is part of. Fair enough.

*But* on the other hand they are offering an web-based de-listing service 
without human interference. Good. After successful delisting, that particular 
IPv6 address becomes immediately de-listed. Fine.


Likely not. Much more likely: After successful delisting, the entire /64 
became immediately de-listed. Then spam from someone within that subnet 
caused it to be listed again. Lather, rinse, repeat.


That tells me, that they must have a setup where individual IPv6 of a blocked /64 subnet become whitelisted. 


How do you arrive at that conclusion?


*That* worked in the past for a very long time. Only recently the whitelisting 
is of a very short time frame.


To the best of my knowledge most if not all DNSBLs are not going to be 
more granular than a /64 on IPv6, nor should they be. The rest of the 
world besides OVH assigns a /64 per customer subnet.


if DNSBLs blocked at the /128 level, every spammer with a normal /64 
subnet would have an immense (ridiculously, insanely, extremely immense) 
number of addresses from which to snowshoe spam. DNSBL database size 
would also rapidly become a problem.


You're in a very bad neighborhood with OVH when it comes to spammers. 
Either move to a better neighborhood or at least demand your own /64 
subnet.




76 or 63 reportings in a /64 subnet aren't necessarily a hint for excessive 
spamming as mentioned in this thread.


76 reports or spamtrap hits within a month for a /64 is a pretty big red 
flag that the subnet is infested with spammers. Industry practice is one 
/64 per customer subnet.


See here: 
https://www.spamhaus.org/faqs/exploits-blocklist-xbl/#how-does-xbl-handle-ipv6-addresses


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Michael Grimm via mailop]

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).
>> …you do. So to:
>>> Is there a way to make that de-listing more persistent?
>> Yes. The following text is fairly instructive:
>> In the last month we have observed 76 listings.
>> 2001:41d0:701:1000::/64 has been detected 76 times in the last month. It has 
>> been removed 7 times.
>> In the last month we have observed 63 listings.
>> 2001:41d0:20a:800::/64 has been detected 63 times in the last month. It has 
>> been removed 4 times.
>> As you can see, it’s the entire /64 getting listed in both cases. They’re 
>> unsavoury neighbourhoods by the look of things.
> 
> And, with IPv6, the "entire /64" should be a single subnet. Either OVH is 
> sharing a /64 amongmultiple customers or OP has another machine that is 
> spamming from within the same subnet.
> 
> 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 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.


But that isn't the point of my initial post: Spamhaus is blocking the /64 
subnet my address is part of. Fair enough. 

*But* on the other hand they are offering an web-based de-listing service 
without human interference. Good. After successful delisting, that particular 
IPv6 address becomes immediately de-listed. Fine.

That tells me, that they must have a setup where individual IPv6 of a blocked 
/64 subnet become whitelisted. *That* worked in the past for a very long time. 
Only recently the whitelisting is of a very short time frame.

76 or 63 reportings in a /64 subnet aren't necessarily a hint for excessive 
spamming as mentioned in this thread. 

Regards,
Michael

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Jay Hennigan via mailop]

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 de-listing more persistent?


Yes. The following text is fairly instructive:

In the last month we have observed 76 listings.
2001:41d0:701:1000::/64 has been detected 76 times in the last month. It has 
been removed 7 times.

In the last month we have observed 63 listings.
2001:41d0:20a:800::/64 has been detected 63 times in the last month. It has 
been removed 4 times.

As you can see, it’s the entire /64 getting listed in both cases. They’re 
unsavoury neighbourhoods by the look of things.


And, with IPv6, the "entire /64" should be a single subnet. Either OVH 
is sharing a /64 among multiple customers or OP has another machine that 
is spamming from within the same subnet.


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.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[John Levine via mailop]

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 with custom kernel even more
>often can be possible. Thus blocking/listing whole /64 is wanted.

Oh, you can do it a lot faster than that by setting static IP addresses.

But we seem to agree, you don't want to share a /64.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Slavko via mailop]

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 possible. Thus blocking/listing whole /64 is wanted.

As the /64 is twice of whole IPv4 mask, plenty "spammers" with
minimal effort, just two/three kernel setting values...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] sendmail queue retry time

[Marco Moock via mailop]

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 regards
Marco

Send spam to 1710429311mu...@cartoonies.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[John Levine via mailop]

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 address reputation aggregates by /64 since it it 
trivial for hosts to
hop around within the /64.  It would not be hard to use a different address for 
every message.  It's
not like you're going to run out.



-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Michael Grimm via mailop]

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 de-listing more persistent?
> 
> Yes. The following text is fairly instructive:
> 
> In the last month we have observed 76 listings.
> 2001:41d0:701:1000::/64 has been detected 76 times in the last month. It has 
> been removed 7 times.
> 
> In the last month we have observed 63 listings.
> 2001:41d0:20a:800::/64 has been detected 63 times in the last month. It has 
> been removed 4 times.
> 
> As you can see, it’s the entire /64 getting listed in both cases. They’re 
> unsavoury neighbourhoods by the look of things.

I know that texts, and I am the one "removed 7 times" and "removed 4 times" 
respectively.

Been there, done that in the past, but *then* the de-listing had been 
*persistent* for months, until I had had to change my IPv6 addresses (new 
public cloud instances).

This changed a couple of days ago.

Regards,
Michael
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Graeme Fowler via mailop]

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 text is fairly instructive:

In the last month we have observed 76 listings.
2001:41d0:701:1000::/64 has been detected 76 times in the last month. It has 
been removed 7 times.

In the last month we have observed 63 listings.
2001:41d0:20a:800::/64 has been detected 63 times in the last month. It has 
been removed 4 times.

As you can see, it’s the entire /64 getting listed in both cases. They’re 
unsavoury neighbourhoods by the look of things.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Michael Grimm via mailop]

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 Spamhaus' de-listing Website 
https://check.spamhaus.org/ and become automatically de-listed thereafter. Only 
until I become listed again, today two times within 6 hours.

Example Case ID and IPv6 addresses involved: 

2001:41d0:20a:800::464
ST4415112 
ST4413096

2001:41d0:701:1000::435d
ST4415103
ST4413113

Is there a way to make that de-listing more persistent?

Thanks in advance and regards,
Michael

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] sendmail queue retry time

[ml+mailop--- via mailop]

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 sendmail.

man sendmail:

   -q[time]
  Process saved messages in the queue at given intervals.  If time
  is omitted, process the queue once. 

Looks like there is no default (maybe your OS uses some startup
command with a "default" retry time).

If you want a non-linear retry:

  MaxQueueAge=age
If this is set to a value greater than zero,
entries in the queue will be retried  during
a  queue  run  only  if the individual retry
time has been reached which is  doubled  for
each  attempt.   The  maximum  retry time is
limited by the specified value.


-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Taavi Eomäe via mailop]

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 that combination due to how hard it is to 
safely implement, but it's not broken (in theory) on its own (but 
caveats apply). Maybe also a couple with ARIA or CAMELLIA, but that's 
even rarer in terms of trying to be compatible. Shouldn't rely on DHE 
because it's a potential DoS risk or RSA KeX because it can't provide 
PFS. But disabling either has probably the biggest impact on backwards 
compatibility.


In the end there really aren't any that are good, there's only a few 
that are better than plaintext.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Matus UHLAR - fantomas via mailop]

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 and key exchanges you're not left 
with a significant amount of backwards compatibility.


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 ?


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fighting for peace is like fucking for virginity...
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[L. Mark Stone via mailop]

> 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 nature in 
> SMTP as argument nowadays. Or i miss something?

Totally agreed Slavko; thanks for putting this so succinctly.  These days (our 
customers are almost all B2B to be fair), we see that the sender has full 
control of the email client, MTA and outbound SEG (if any) which then sends the 
email directly to the recipient's inbound SEG (if any), MTA, and email client.

No middlemen any more not under the clear control of either the sender or the 
recipient that we see, so no excuse not to be able to support >/= TLS 1.2 with 
known secure ciphers.

Regards, 
Mark 
_ 
L. Mark Stone, Founder 
North America's Leading Zimbra VAR/BSP/Training Partner 
For Companies With Mission-Critical Email Needs

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Andrew C Aitchison via mailop]

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
morning I deleted the mail from mqueue.


That's a fairly aggressive retry strategy.


That is the default in sendmail.

Is there any standard that defines the retry rates or at least a best
practise?


The exim default is (description from the documentation):

*   *   F,2h,15m; G,16h,1h,1.5; F,4d,6h

This causes any temporarily failing address to be retried every 15
minutes for 2 hours, then at intervals starting at one hour and
increasing by a factor of 1.5 until 16 hours have passed, then every 6
hours up to 4 days. If an address is not delivered after 4 days of
temporary failure, it is bounced. The time is measured from first
failure, not from the time the message was received.



It depends on the average queue size and contention of the queue.
With many entry a queue runner interval might be exhausted easily and
retry streches over multiple intervals.
I would regard a 10 to 15 minute queue runner interval as acceptable.
If the queue is nearly empty the retry happens 4 to 6 times a hour.
That's not very aggressive meanwhile.


Exim's queue runner doesn't try to deliver every mail on every run through.
I hadn't expected that other queue runners would.


Our inbound queuerunner operates in permanent queue running mode which
could lead to a retry every minute if the queue is nearly empty.
This is more or less "aggressive" ...


An *inbound* queue runner sounds like a special case
- I would expect it to be more "aggressive".

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Johann Klasek via mailop]

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 least 30 minutes...

A recommendation from the year 2008, one might re-consider this under
today's standards.

Beside this, MTA queue runners implement some dynamically calculated
backoff strategy based on time interval stretching (usually exponential)
or priority based, or a combination of these strategies.

Johann

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Johann Klasek via mailop]

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.  
> > 
> > That's a fairly aggressive retry strategy.
> 
> That is the default in sendmail.
> 
> Is there any standard that defines the retry rates or at least a best
> practise?

It depends on the average queue size and contention of the queue.
With many entry a queue runner interval might be exhausted easily and
retry streches over multiple intervals.
I would regard a 10 to 15 minute queue runner interval as acceptable.
If the queue is nearly empty the retry happens 4 to 6 times a hour.
That's not very aggressive meanwhile.
Our inbound queuerunner operates in permanent queue running mode which
could lead to a retry every minute if the queue is nearly empty.
This is more or less "aggressive" ... 

Johann

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Slavko via mailop]

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/

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Marco Moock via mailop]

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 there any standard that defines the retry rates or at least a best
practise?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Slavko via mailop]

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? Open relays are gone, source routing is gone, 
forwarding is not as simple as it was in past (it must be done properly)...


I mean, that one will delivery message to recipient's MX host directly, 
not over random (unknown) hops, in worse case it will delivery it to 
backup MX (but that haven't be random hop). Thus we can assume target MX 
as final target in public net.


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 nature in 
SMTP as argument nowadays. Or i miss something?


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

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[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. If there's something about
that message gmail doesn't like, then retrying that often might be
enough to reinstate the limit each time.
Generally best to back off the retry rate after a couple of hours.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Marco Moock via mailop]

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, and from time
> to time also rate-limits me. Which I don't care about, because I send
> very little mail, and it goes through on the next run.

sendmail tried to deliver it 20 times during the night - this morning
I deleted the mail from mqueue.

Other mails to Google now go through, so it seems it is not a complete
limitation of my IP address/ISP.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Julian Bradfield via mailop]

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 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 unsolicited mail
> originating, stat=Deferred: 421-4.7.28 Gmail has detected an unusual
> rate of unsolicited mail originating
>
> It was only this message. Why don't they reject them with 5xx when they
> treat the mail as unsolicited?
> It was only this mail, my server wasn't abused by spammers.
>
> Although, I send only a very small amount of mail to Google. Do they
> use that to calculate the rate?

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, and from time
to time also rate-limits me. Which I don't care about, because I send
very little mail, and it goes through on the next run.

Google is brain-dead about "unsolicited" mail - whatever machine
learning it's doing, is crap.

Their latest daftness (latest in my noticing it, anyway) is
rate-limiting on the basis of too many recipients for a single
message-id, where "too many" varies from 6 to 30. You'd think they'd
never heard of organization mailing lists.

Julian.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Cyril - ImprovMX via mailop]

>
> 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 à 10:45, Gellner, Oliver via mailop 
a écrit :

> 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.
> > 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.
>
> 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.
> For services which only allow encrypted connections I'm all for removing
> support for TLS 1.1 and everything below. But we cannot enforce TLS on the
> public MX servers as long as no large ESPs make this move first.
>
> --
> BR Oliver
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Marco Moock via mailop]

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., dsn=4.7.28,
> > reply=421 4.7.28 Gmail has detected an unusual rate of unsolicited
> > mail originating, stat=Deferred: 421-4.7.28 Gmail has detected an
> > unusual rate of unsolicited mail originating  
> 
> The full message from Gmail gives you more hints about the problem: it
> may be a rate limiting for the DKIM signing domain, for the SPF
> domain, for an URL included in the email, for the sender and so on.

IIRC it was the DKIM signing domain, but I can't see the full message
in the sendmail log.

> You need the full message to make a better guess, but, for example, if
> Google is receiving a lot of spam with a given URL domain in the body
> it may start rate limiting that content from every source, including
> you.

Is there a test address at google where I can send such messages to
test it?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Cyril - ImprovMX via mailop]

>
> 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
transaction), which is the entire point of forcing to upgrade the security?

Or, if I take the idea the other way around, assuming that "TLS encryption
in SMTP is hop-by-hop" and implying that some hop won't be as secure, isn't
then having TLS encryption a false sense of security ?

(If my message appears aggressive or disrespectful, I'm sorry, that isn't
my intention).

Le jeu. 14 mars 2024 à 10:24, Andrew C Aitchison via mailop <
mailop@mailop.org> a écrit :

> 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 back to no encryption. That is the
> > default setting and only a small amount of servers makes using STARTTLS
> > mandatory for outgoing mail - too many situations when it fails.
>
> 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.
>
> For IMAP and POP, encryption is end-to-end, but there you know, and
> presumably have control over, your users.
>
> --
> Andrew C. Aitchison  Kendal, UK
> and...@aitchison.me.uk
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Gellner, Oliver via mailop]

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.
> 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.

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.
For services which only allow encrypted connections I'm all for removing 
support for TLS 1.1 and everything below. But we cannot enforce TLS on the 
public MX servers as long as no large ESPs make this move first.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Gellner, Oliver via mailop]

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 deprecated in March 2021 (RFC 8996). Systems that
> are unable to use TLS 1.2/1.3 had not been updated for at least 8-10
> years. I don't see why I should accept mails from these hosts. In fact
> since we stopped accepting TLS 1.0/1.1 we have also reduced the number
> of spam delivery attempts as these hosts are almost always on of these
> old and never updated hosts …

The majority of messages which we receive over TLS 1.0 or 1.1 is not spam. 
Actually TLS 1.1 has a smaller share than 1.0, it seems most systems that 
support 1.1 also support 1.2.

I can't really tell from the outside why those systems are using old TLS 
versions, some possible reasons might be:
- expired maintenance so they cannot update their appliance
- software that is written in programming languages which do not natively 
support TLS 1.2 like Java 6
- or most probably because they are located in parts of the world where they 
have other problems than the TLS version in use.
In fact most of those messages do not originate from sources in Western Europe 
or North America. If we disable TLS 1.0 those messages will be transmitted in 
clear text or not at all instead of securely encrypted. Precisely from a 
security perspective this would be a disservice to our users.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[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., dsn=4.7.28,
> reply=421 4.7.28 Gmail has detected an unusual rate of unsolicited mail
> originating, stat=Deferred: 421-4.7.28 Gmail has detected an unusual
> rate of unsolicited mail originating

The full message from Gmail gives you more hints about the problem: it
may be a rate limiting for the DKIM signing domain, for the SPF
domain, for an URL included in the email, for the sender and so on.

E.g. the full message could be like this:
421-4.7.28 Gmail has detected an unusual rate of unsolicited mail originating
421-4.7.28 from your DKIM domain [#redacted#  36]. To protect
421-4.7.28 our users from spam, mail sent from your domain has been temporarily
421-4.7.28 rate limited. For more information, go to
421-4.7.28  https://support.google.com/mail/?p=UnsolicitedRateLimitError to
421 4.7.28 review our Bulk Email Senders Guidelines. #redacted# - gsmtp

The SPF tempfail error starts with the same words, too.
The URL one have a different prehamble.
I don't know how many other errors you can get, but if you want to
investigate you need the full error.

> It was only this message. Why don't they reject them with 5xx when they
> treat the mail as unsolicited?

They give you a tempfail because it is a rate limiting: so if you try
later it usually will work.

> It was only this mail, my server wasn't abused by spammers.
>
> Although, I send only a very small amount of mail to Google. Do they
> use that to calculate the rate?

You need the full message to make a better guess, but, for example, if
Google is receiving a lot of spam with a given URL domain in the body
it may start rate limiting that content from every source, including
you.

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Andrew C Aitchison via mailop]

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 back to no encryption. That is the
default setting and only a small amount of servers makes using STARTTLS
mandatory for outgoing mail - too many situations when it fails.


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.

For IMAP and POP, encryption is end-to-end, but there you know, and 
presumably have control over, your users.


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Google unsolicited mail rejected with 421

[Marco Moock via mailop]

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=, 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 unsolicited mail
originating, stat=Deferred: 421-4.7.28 Gmail has detected an unusual
rate of unsolicited mail originating

It was only this message. Why don't they reject them with 5xx when they
treat the mail as unsolicited?
It was only this mail, my server wasn't abused by spammers.

Although, I send only a very small amount of mail to Google. Do they
use that to calculate the rate?

-- 
kind regards
Marco
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] PlanetHoster contact

[Romain via mailop]

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 their customer.
>
> Thank you!
>
> Romain
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Marco Moock via mailop]

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 and only a small amount of servers makes using STARTTLS
mandatory for outgoing mail - too many situations when it fails.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Cyril - ImprovMX via mailop]

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 deprecated
versions would force those users to be compliant and improve the general
security.

If we decide to keep old versions in place because not everyone can
upgrade, will we still accept TLS 1.0 in 10 years from now ? 20 ? 50 ?

And if that's the case, why bother working on more secure ciphers ?

Le mer. 13 mars 2024, 22:24, Thomas Walter via mailop  a
écrit :

>
>
> On 13.03.24 18:55, Slavko via mailop wrote:
> > Dňa 13. marca 2024 16:32:42 UTC používateľ Andrew C Aitchison via mailop
>  napísal:
> >
> >> Has anyone checked what traffic is still using TLS 1.0 or TLS 1.1 ?
> >
> > Yes, some infected machines from DZ, BR, AR, ID and so :-)
> So we are removing a perfectly good marker to increase spam scores?
>
> Just saying... :-)
>
> Regards,
> Thomas Walter
>
> --
> Thomas Walter
> Datenverarbeitungszentrale
>
> FH Münster
> - University of Applied Sciences -
> Corrensstr. 25, Raum B 112
> 48149 Münster
>
> Tel: +49 251 83 64 908
> Fax: +49 251 83 64 910
> www.fh-muenster.de/dvz/
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] PlanetHoster contact

[Romain via mailop]

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
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop