Greg A. Woods wrote in <[email protected]>: |At Tue, 23 Apr 2024 01:41:11 +0200, Steffen Nurpmeso <[email protected]> \ |wrote: |Subject: Re: Mail delivery from Postfix to remote IMAP |> |> SPF should never have been introduced | |I agree _VERY_ much! It still does absolutely nothing to reduce SMTP |abuse or increase trust in any way whatsoever.
Well -- there are people which disagree; and they seem to matter. I personally think the RFC as such is a true masterpiece, in my eyes (fwiw). A lot of thought and energy where used, to think the concept "to the last leaf" that noone normally uses. And if you have (a) fixed IP(s), and all that, then SPF can secure one hop. And if you are an organizational unit like some *bsd.org, or a university, or cpan.org, or any such, you can setup SRS or create permanent pseudo addresses the way dmarc.ietf.org does it, and rewrite the emails. Likewise any DKIM-will-be-broken thing can do the same "(temporary) shadow address)" when receiver DNS entries notify that this will cause trouble (aka DMARC etc). But i always say that all for one has to be done, increases the complexity massively, and that is surely one reason why so many little ones just give up. I say email should be easy. Reality is that most infrastructure do not do any of the above, and so basic concepts of email, like "simple forwarding by alias", or "mailing lists" "fail badly". Anyhow i used SPF from 2015 to 2024, i had "-all" and that seemed to be a good thing, until last year suddenly an email reply to an address behind a FreeBSD.org caused a bounce, and their postmaster just said it "works as designed" i think were his words. So i changed it to "~all" due to that, but what is a SPF record with "~all" worth? i said. So i said i write a DKIM signed, and have a cryptographically verifiable host-specific signature, and i give a shit how many hops or which mystic ways the emails take, as long as they end up where they should, and throw away the SPF DNS entry. Unfortunately the entire ecosystem is at least "from bug to fix", but sometimes all the time, grazy, and penaltizes messages without the glorified SPF, or with a message ID which contains the sender address plain, or which contains a Received: header with an "invalid IP" (even though that was inside a VPN and a follow-up Received: had the same domain name with one sub- lesser), and all that. I personally always (now) say that i do not understand any of that, i would go for only DKIM, and slightly redesign it (as already mentioned). You know, a TLS connection does not even establish, likewise SSH, why should email be any different given that the tool is there. And throw away all the others. The only thing is that the host key could be stolen, but effectively that has the same risk as any web- or mail- or etc server that uses server certificates; at times where most servers live in virtual boxes (somewhere in the clowd) total trust to the virtual (clowd) providers is anyway necessary, already. This still breaks mailing-lists then, at least those which modify the (covered) message (parts). There is no way out of that (i totally reject ARC), but if the mailing-list verifies DKIM, and creates a DKIM signature itself, i imagine, that is, email programs could offer the possibility to "trust this". Effectively the mailing-list creates a new message, then. It will produce the ugly "x via y" From:, or go the IETF "dmarc".ietf.org "pseudo subscriber address" way. Anyway that is my opinion. Throw away all this tremendously bloated infrastructure and keep only DKIM. SPF with the "~all" that a normal person needs who could possibly contact an alias that will then fail is a mess, that much is plain. By the way in practice most of the email spam i receive comes via Google, and these have all the weapons in place. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
