|
|
Subscribe / Log in / New account

Invalid recommendations

Invalid recommendations

Posted Nov 29, 2024 18:00 UTC (Fri) by Curan (subscriber, #66186)
In reply to: Invalid recommendations by mpr22
Parent article: Book review: Run Your Own Mail Server

Well, in the end it is about me, isn't it? If I follow the example of big e-mail providers, I will reject anybody who doesn't have SPF/DKIM. It's just, that in my experience: that doesn't help. Actual spam e-mails have those valid headers most of the time. So my improvement is in the point zero-zero-x range, once I add SPF/DKIM in- and outbound.

But you are correct in the basic statement. Directly only my outbound e-mails would be affected. And to be honest: I never saw the reason why a MTA could accept my e-mails today, but not the next day, because I didn't have DKIM/SPF. It is just bullshit compliance theatre, imposed by organisations like CISA/BSI/ENISA/… (in my humble opinion).


to post comments

Invalid recommendations

Posted Nov 29, 2024 18:28 UTC (Fri) by pizza (subscriber, #46) [Link] (4 responses)

> It is just bullshit compliance theatre, imposed by organisations like CISA/BSI/ENISA/… (in my humble opinion).

SPF/DKIM only attests that the sender is allowed to send on behalf of their domain. That by itself has *significantly* cut down on the amount of outright fradulent or malicious stuff landing in folks' inboxes -- think phising or worse, where the sender is actively trying to hide the origin of their messages.

The latter used to _heavily_ rely on spoofing legitimate domains via open relays or compromised systems; now those folks have to rely on stolen credentials, with a narrow window before the provider shuts it down.

Of course DKIM/SFP does nothing for "legitimate" [1] UCE, but then it's not supposed to.

[1] "unsolicited commercial email" where the sender is who they claim they are, aka what we traditionally referred to as "spam"

Invalid recommendations

Posted Nov 29, 2024 18:45 UTC (Fri) by Curan (subscriber, #66186) [Link] (3 responses)

Your response relies on the premise, that „modern“ spammers are still rely on faked sending addresses. In my experience spam comes from two sources:
- barely secured domains (the spammers got a "legitimate" account, even though the operator would say "not an actual user")
- domains created for spamming

There is a (comparatively) small amount of e-mails that would be caught by SPF and/or DKIM.

Invalid recommendations

Posted Nov 30, 2024 13:24 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (2 responses)

> There is a (comparatively) small amount of e-mails that would be caught by SPF and/or DKIM.

Might this, perhaps, be *because* they are enforced? That is, they've been required long enough that what they prevent has indeed been extinguished, but it is still cheap enough even with these being required to churn out junk email that it *appears* nothing has changed? Short of charging per email exchanged or much higher registration fees…what is actually going to increase costs for these operators?

Invalid recommendations

Posted Nov 30, 2024 13:48 UTC (Sat) by pizza (subscriber, #46) [Link]

>> There is a (comparatively) small amount of e-mails that would be caught by SPF and/or DKIM.
> Might this, perhaps, be *because* they are enforced?

Yes, exactly this.

This discussion reminds me of Y2K, afterwards, laypeople (and many that should know better!) were going "what was the big deal, the world didn't end, we're not going to believe the next so-called panic" completely missing the fact that it was a non-event only because obscene amounts of effort went into fixing everything up (barely) in advance.

Invalid recommendations

Posted Nov 30, 2024 16:53 UTC (Sat) by Curan (subscriber, #66186) [Link]

That is probably correct, but it doesn't help me, does it? My spam levels haven't dropped with SPF/DKIM, so it is, from my POV, just pointless. But we can of course argue semantics here. And obviously I would never be able to prove, that the situation wouldn't be worse, if we didn't have these.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds