Re: [mailop] o365 outbound senders.. Strange Failures sending .. widespread reports

[Benny Pedersen via mailop]

Michael Peddemors via mailop skrev den 2023-12-18 23:54:


Maybe my original posting wasn't clear..


+1

You would see these in your inbound logs, coming from o365 via port 
25/TLS...


i have no logs of this here, so it can be differing on diff servers

Just real strange widespread occurrence that you would not expect to 
make it through o365 rules.


yes spammers is smart sometimes
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] o365 outbound senders.. Strange Failures sending .. widespread reports

[Michael Peddemors via mailop]

On 2023-12-18 14:20, Benny Pedersen via mailop wrote:

Michael Peddemors via mailop skrev den 2023-12-18 22:45:

Strange rewriting mechanism, but this kind of volume should be 
restricted from the o365 side, no? What about the usage of 
non-existant FQDN name in the MAIL FROM?


what mta ?

what port is used ?

i use postfix with postscreen on port 25, in port 465, 587 is dnsbl from 
spamrats, before sasl auth


Maybe my original posting wasn't clear..

You would see these in your inbound logs, coming from o365 via port 
25/TLS...


Just real strange widespread occurrence that you would not expect to 
make it through o365 rules.



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

Re: [mailop] o365 outbound senders.. Strange Failures sending .. widespread reports

[Benny Pedersen via mailop]

Michael Peddemors via mailop skrev den 2023-12-18 22:45:

Strange rewriting mechanism, but this kind of volume should be 
restricted from the o365 side, no? What about the usage of non-existant 
FQDN name in the MAIL FROM?


what mta ?

what port is used ?

i use postfix with postscreen on port 25, in port 465, 587 is dnsbl from 
spamrats, before sasl auth


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

Re: [mailop] ECDSA DKIM validation?

[Bill Cole via mailop]

On 2023-12-18 at 15:03:16 UTC-0500 (Mon, 18 Dec 2023 15:03:16 -0500)
Michael W. Lucas via mailop 
is rumored to have said:

> Hi,
>
> Last I checked a few years ago, validation of ECDSA DKIM keys was
> still iffy on deployed servers. Has the situation improved? Can we
> recommend ECDSA DKIM yet without ruining people's day?

Exclusively? Not yet.

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] ECDSA DKIM validation?

[Michael W. Lucas via mailop]

Hi,

Last I checked a few years ago, validation of ECDSA DKIM keys was
still iffy on deployed servers. Has the situation improved? Can we
recommend ECDSA DKIM yet without ruining people's day?

Thanks,
==ml

-- 
Michael W. Lucashttps://mwl.io/
author of: Absolute OpenBSD, SSH Mastery, git commit murder,
 Absolute FreeBSD, Butterfly Stomp Waltz, Forever Falls, etc...
### New books: DNSSEC Mastery, Letters to ed(1), $ git sync murder ###
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is anyone seeing new temporary errors from Gmail?

[Frost The Fox via mailop]

I see a very small amount of these throughout our logs for the past few
days (<10). A bit more today, mostly centered around 19:40-19:44 UTC, but
it is a very small fraction of our mail that hour (~42 of 47087). Nothing
since. For us, they cleared almost immediately on a retry, so I'm inclined
to say just something on Gmail's end as the code suggests.

Thanks,
Frost

On Mon, Dec 18, 2023 at 1:44 PM Brian Kowalewicz via mailop <
mailop@mailop.org> wrote:

> Hi,
>
>
> In the last 5 hours or so, we've been seeing this from Gmail on a fraction
> of our traffic:
>
>
> "Message failed: 451-4.3.0 Mail server temporarily rejected message. For
> more information, go to 451 4.3.0
> https://support.google.com/a/answer/3221692 "
>
>
> Doesn't look like the new* 421 4.7.28 errors.*
>
>
> Is Gmail having issues or am I?
>
>
> Thanks,
>
>
> Brian
>
>
>
>
> ___
> 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] Is anyone seeing new temporary errors from Gmail?

[Brian Kowalewicz via mailop]

Hi,


In the last 5 hours or so, we've been seeing this from Gmail on a fraction of 
our traffic:


"Message failed: 451-4.3.0 Mail server temporarily rejected message. For more 
information, go to 451 4.3.0 https://support.google.com/a/answer/3221692 "


Doesn't look like the new 421 4.7.28 errors.


Is Gmail having issues or am I?


Thanks,


Brian



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

Re: [mailop] DKIM / slippery slope gmx.de

[Slavko via mailop]

Dňa 18. decembra 2023 16:00:17 UTC používateľ ml+mailop--- via mailop 
 napísal:
>On Mon, Dec 18, 2023, Paul Smith* via mailop wrote:

>> Amazon, etc. They send mail pretending to be from someth...@amazon.com.
>
>That's why DKIM can be useful for those who want to prevent forgeries.

From: s...@amazon.com
DKIM-Signature: ... d=spammer.com

If signature (and related DNS record) is valid, AFAIK that will result in "pass"
(by RFC). How that will prevent forgery, please?

With DMARC the forgery is another story.

>Why should everyone else be forced to do that?

IMO for tracking purpose... Either, for good reason -- to track DKIM's domain
reputation, or other reason, as signed user@domain is more reliable source
than random user@domain (and signed forever).

regards


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

Re: [mailop] DKIM / slippery slope gmx.de

[Louis Laureys via mailop]

> That's why DKIM can be useful for those who want to prevent forgeries.
> Why should everyone else be forced to do that?

We all know email is forgeable, but no non-technical person has this
expectation. Slowly moving email to a non-forgeable future is a good idea if you
ask me, as it aligns with what people expect. Any reputation tracking benefits
you get from that are a bonus (to me), since indeed most users are using
freemail domains anyway.

To get to that non-forgeable future though, enforcement needs to start happening
at some point. Otherwise, we'll stay right where we are. You may not mind that,
but most do.


Groetjes,
Louis


Op maandag 18 december 2023 om 17:00, schreef ml+mailop--- via mailop
:

> On Mon, Dec 18, 2023, Paul Smith* via mailop wrote:
> 
> > DKIM (and SPF) aren't anti-spam measures, and have never been promoted as
> > such. They're anti-forgery measures.
> 
> I know that -- which is why I don't use either (besides other reasons,
> e.g., breaking existing mail mechanisms).
> 
> > spammers can piggy-back on the good reputation of big companies like Google,
> 
> As I mentioned before: 90% of the spam I get is from gmail --
> that's a "good reputation"?
> 
> > Amazon, etc. They send mail pretending to be from someth...@amazon.com
> [someth...@amazon.com].
> 
> That's why DKIM can be useful for those who want to prevent forgeries.
> Why should everyone else be forced to do that?
> 
> --
> 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 [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM / slippery slope gmx.de

[Jaroslaw Rafa via mailop]

Dnia 18.12.2023 o godz. 14:49:50 Paul Smith* via mailop pisze:
> Spam filters handle reputation of things. One thing they can do is
> track reputation of sender domains. When forgery is possible, then
> that means that spammers can piggy-back on the good reputation of
> big companies like Google, Amazon, etc. They send mail pretending to
> be from someth...@amazon.com. There's no reliable way for the
> recipient to know that it's not actually from Amazon, so the
> recipient has to either:

Do content analysis. Do content analysis. Do content analysis. Do content
analysis...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM / slippery slope gmx.de

[ml+mailop--- via mailop]

On Mon, Dec 18, 2023, Paul Smith* via mailop wrote:

> DKIM (and SPF) aren't anti-spam measures, and have never been promoted as
> such. They're anti-forgery measures.

I know that -- which is why I don't use either (besides other reasons,
e.g., breaking existing mail mechanisms).

> spammers can piggy-back on the good reputation of big companies like Google,

As I mentioned before: 90% of the spam I get is from gmail --
that's a "good reputation"?

> Amazon, etc. They send mail pretending to be from someth...@amazon.com.

That's why DKIM can be useful for those who want to prevent forgeries.
Why should everyone else be forced to do that?

-- 
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] DKIM / slippery slope gmx.de

[Paul Smith* via mailop]

On 18/12/2023 10:18, ml+mailop--- via mailop wrote:

And it seems none of the extra requirements do anything against
spam, because the spammers can (and do, see above) easily implement
all of those.


DKIM (and SPF) aren't anti-spam measures, and have never been promoted 
as such. They're anti-forgery measures.


Spam filters handle reputation of things. One thing they can do is track 
reputation of sender domains. When forgery is possible, then that means 
that spammers can piggy-back on the good reputation of big companies 
like Google, Amazon, etc. They send mail pretending to be from 
someth...@amazon.com. There's no reliable way for the recipient to know 
that it's not actually from Amazon, so the recipient has to either:


- let the mail through (because it says it's from Amazon, so must be OK) 
- damage the reputation of Amazon (because spam comes from amazon.com) - 
or don't use the sender domain for reputation tracking, because it's 
unreliable


The first two options are obviously bad, and the third takes away a big 
tool from the anti-spam arsenal.


When you have SPF and/or DKIM, then you've essentially prevented forgery 
(yes, you may have introduced other problems, but that's by-the-by). So, 
it's irrelevant that spammers can implement these features - that's 
actually good - the spammers can't use a trustworthy sending domain to 
try to trick spam filters, so the spam filter can track the reputation 
of the REAL sending domain, and spammers get punished and the 
trustworthy domains (theoretically) don't.


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

Re: [mailop] DKIM / slippery slope gmx.de

[Andy Smith via mailop]

Hello,

On Mon, Dec 18, 2023 at 01:01:58PM +0200, Taavi Eomäe via mailop wrote:
> > And it seems none of the extra requirements do anything against
> spam, because the spammers can (and do, see above) easily implement
> all of those.
> 
> I get the impression you can't see the forest for the trees. These methods
> being easy to implement is exactly the goal. Once majority of mail is
> properly authenticated more effective methods can be used to fight spam

While I do think that without SPF and DKIM, the spam problem would
be lots worse right now, we are somewhat stymied by the fact that
the foundation of authentication at present is the domain name.
Which are trivially cheap, and keep growing in availability.

For email there is no easy fix for that and it leads us towards a
future where just DKIM-signing as an existing domain name with no
negative reputation is not enough, since you share that same level
of reputation with countless other spammer domains minted on the
same day. Some would say we are already there, with "your domain
doesn't have enough positive reputation" being a "reason" for a
non-delivery.

Maybe at some point in the near future senders will not only want to
DKIM-sign with the aligning domain name but also their other,
more-established domains, to show the link between them and
assert that some new domain should be treated the same?

If that happens, some will say it's another requirement, another
frog-boiling exercise, but it's just the way things are being
driven. The problems can't be simply ignored.

In other news, I read that Gmail and the Linux Kernel Mailing List
got into a staring competition over rate of email sending, and LKML
blinked first, in deciding to reduce the amount of email they send:

https://lwn.net/Articles/950567/

Now, in the linked email from Konstantin, Konstantin does say that
reducing the amount of mail sent would make the list generally more
readable, and only then goes on to mention Gmail's policies twice,
so we might think this is not primarily about Gmail. However, in the
comments section Konstantin also adds:

 > Having mail in the queue for retry is not a problem.

 Yes, it's a problem, because the person [at Gmail] then cannot
 receive *any* mail from us. When Greg KH used to send
 rapid-succession stable patchbomb series of 100-500 messages to
 linux-kernel, that meant nobody at gmail who is subscribed to
 LKML was able to receive any mail from us until their quotas
 cooled off. Thankfully, Greg doesn't do that any more after
 switching to the dedicated patches list.

 Huge queues also degrade performance, but it's less of a
 concern for us because Postfix is pretty good at managing huge
 queues and the systems that are sending out these mails are
 very beefy.

Gmail publishes its rate-limits and they've always been there.
They're not part of SMTP though; they're a Gmail policy. One can
have views on whether a mailing list with 30k messages a month is
sane, but people opted in to receive that mail and it's not spam.
LKML has decided to change its behaviour, rather than just tell
Gmail users to deal with it.

So we all have to change our behaviours sometimes and a lot of the
time that change is going to be forced by the giant mailbox
providers.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM / slippery slope gmx.de

[Taavi Eomäe via mailop]

> And it seems none of the extra requirements do anything against
spam, because the spammers can (and do, see above) easily implement
all of those.

I get the impression you can't see the forest for the trees. These 
methods being easy to implement is exactly the goal. Once majority of 
mail is properly authenticated more effective methods can be used to 
fight spam as content-based filtering is increasingly difficult, 
sender-based will get somewhat more attention.


These two errors from an another thread on this list are a great example:

> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail 
originating from your SPF domain [userdomain.tld 15]. To protect our 
users from spam, mail sent from your domain has been temporarily rate 
limited. For more information, go to 
https://support.google.com/mail/?p=UnsolicitedRateLimitError to review 
our Bulk Email Senders Guidelines. 
o13-20020a056870200d00b002033c710f0asi2122725oab.109 - gsmtp


> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail 
originating from your DKIM domain [ 15]. To protect our users from spam, 
mail sent from your domain has been temporarily rate limited. Please 
visit https://support.google.com/mail/?p=UnsolicitedRateLimitError to 
review our Bulk Email Senders Guidelines. 
y5-20020a056808130500b003b3eaa2eb4esi890433oiv.53 - gsmtp


Anyways, it's about time hosts start punishing lack of DKIM (more).


Best regards,
Taavi Eomäe



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

Re: [mailop] DKIM / slippery slope gmx.de

[ml+mailop--- via mailop]

On Mon, Dec 18, 2023, Gellner, Oliver via mailop wrote:
> On 17.12.2023 at 21:48 Michael Peddemors via mailop wrote:

> > A bit off topic, but it is always amazing.. rejecting based on no DKIM?

> > It's like most new requirements, ever notice that the spammers are 
> > implementing these requirements sooner/faster than the real email operators 
> > and domains?

> > I still think we as an industry are going down a slippery slope..

> especially not the end users, understand DKIM, but a person who
> is responsible for running a mail server should. So my take on

I understand DKIM (I even implemented it in an MTA) but I don't use it.

One requirement after the other... dying a slow death...
(see boiling frog parable)

And it seems none of the extra requirements do anything against
spam, because the spammers can (and do, see above) easily implement
all of those.

-- 
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] Merry Christmas from Google?

[Byung-Hee HWANG via mailop]

> That depends on the setting of the forwarder. Some organizations use
> aliases for forwarding, Envelope-Sender won't change in that case
> unless other rulesets change it.

Yes, that is true:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043539#88


Sincerely, Byung-Hee
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] 451-Reject due to policy restrictions from web.de and gmx.de

[Gellner, Oliver via mailop]

On 17.12.2023 at 21:48 Michael Peddemors via mailop wrote:

> On 2023-12-13 16:08, Randolf Richardson, Postmaster via mailop wrote:
>>  We're not seeing that error in our mail server logs here in Canada.
>>
>>  The trend seems to be that mail servers worldwide have gradually
>> been adding DKIM signing to all outbound mail, and some are starting
>> to require it of all inbound mail (we're also considering making DKIM
>> signing a requirement for all inbound mail).
>>
>>  Feel free to ask if you have any questions about getting these
>> things set up -- the SPF and DMARC part is very easy, and the DKIM
>> part takes a bit of work that's well worth the effort.
>>
>>  Getting everything configured and tested over a few days or a
>> weekend is a realistic possibility (depending on the size and
>> complexity of your system, of course), and could be a nice gift for
>> your users if it's working before Christmas.
>>
>>> Hello all,
>>>
>>> do any of you who do not live in Germany have this error message from
>>> GMX and WEB.DE? Or is this an educational measure for German providers only?
>>>
>>> 451-Requested action aborted\n451-Reject due to policy
>>> restrictions.\n451 For explanation visit https://postmaster.gmx.net/de/
>>> https://postmaster.gmx.net/en/case?c=r0103
>>>
>>> Hundreds of domains go through our servers, should we now explain to
>>> every customer that if they, as German citizens, want to send an e-mail
>>> to other German citizens, especially if they live with Web or GMX.de,
>>> they must first populate their domains with DKIM entries? Cool thing,
>>> especially so close to Christmas.
>>>
>>> Kind regards
>>> Andreas

> A bit off topic, but it is always amazing.. rejecting based on no DKIM?
> It's like most new requirements, ever notice that the spammers are 
> implementing these requirements sooner/faster than the real email operators 
> and domains?
> Spammers got SPF down pat a lot faster.. they adopted TLS faster.. List 
> unsubscribe formats, even DNS they nailed it faster than most large 
> companies..
> I still think we as an industry are going down a slippery slope.. Email 
> should not be complicated And those companies with some of the tightest 
> restrictions, are also the source of some of the worst spam..
> The litany of sill acronyms needed to operate an email server, have added 
> layer on top of layer, without truly solving the underlying needs that 
> promoted their use in the first place..
> Are we moving towards a walled garden, where only the largest email providers 
> are allowed to play?


I don't believe that DKIM is a good example for a walled garden, as it is an 
open standard. It's also not necessary that everyone, especially not the end 
users, understand DKIM, but a person who is responsible for running a mail 
server should. So my take on the original question is that it is a reasonable 
expectation that domains are populated with DKIM entries. If you have customers 
that send unauthenticated emails then you should change this quickly, 
regardless of the changes at GMX. Google is introducing a similar requirement 
in one month and I know email service providers that add a significant amount 
of spam points to every unauthenticated incoming message since at least 2017.

Conversely DKIM does not give you a free pass into the inbox. It just allows 
filtering based on domains instead of IP addresses which is a necessary 
improvement in times of email-as-a-service with shared IP space. So if spammers 
implement DKIM as well this won't help them.

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