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
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
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
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
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
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
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
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:
> 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
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,
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
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
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
> 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
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
> 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
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
17 matches
Mail list logo
