Alessandro Vesely wrote in
<34f44d43-09f1-4dbb-9b9e-11391a022...@tana.it>:
|On 15/11/2024 20:13, Dave Crocker wrote:
|> On 11/15/2024 10:55 AM, Alessandro Vesely wrote:
|>> On 13/11/2024 21:14, Dave Crocker wrote:
|>>> While 'indirect' has well-established context in many email technical
|>>> circles, I believe it does not have clear, consistent, and precise
|>>> meaning. So it needs to be defined here, with more than an example.
|>>>
|>>> I see this is an extremely important point, since the movement that
|>>> has taken place with email is to consider tight integration of domain
|>>> name and sending platform, in substantial contrast with the way email
|>>> worked for perhaps 40 years. That is, 'indirect' is tending to be
|>>> treated as almost aberrant, or at least as problematic.
|>>
|>> I prefer the latter term, "problematic", rather than "aberrant" or,
|>> according to the upcoming SMTP standard, "misguided".
|>
|> You might prefer more comfortable language but I was characterizing the
|> very problematic tone that I perceive permeating work in this space, in
|> recent years, and am trying to highlight how that tone establishes a
|> counter-productive approach to dealing with these issues.
|
|DMARC is the only current approach toward a deterministically "clean"
|email environment, AFAIK. I wonder if those who dispraise it have an
|alternative in mind or would just prefer a free for all.
Any DNS record to be interpreted as "emails from here include
a DKIM signature" will do. No?
It could even be empty. Nix URIs, nix "actions", nix anything.
Here is a DKIM signature, bounce with according SMTP code if DKIM
signature is missing or verification fails.
Period.
|> Another example of this aberrant view is the insistence on misusing the
|> word 'spoofing'.
|
|As the antonym of "legit"?
|
|>> Sadly, Section 3.4 of rfc5321bis doesn't define forwarding any better.
|>> Its definition of what "can be treated as a continuation of email
|>> transit" is overly strict. In particular, forwarding that is limited
|>> to the set of modifications and actions described there never breaks
|>> typical DKIM signatures.
|>
|> MTA relaying, vs. mediator -- eg, mailing list -- forwarding.
|>
|>> Reality differs.
|>
|> I understand both those words, but not this combined use of them.
|
|IMHO forwarding should be considered as a continuation of transit,
|albeit it can be enriched with marginal annotations. I agree it is
|outside SMTP proper, but neither it is equivalent to composing brand new
|messages. The latter is what SMTP states, which is different from the
|commonly accepted meaning of "forwarding".
|
|In particular, we should find methods whereby From: doesn't have to be
|changed. (Not that it's SMTP the one which forces to change it, but it
|agrees to.)
In my opinion. That is what i said "all these years".
I changed my mind if only email gets easy again.
Regarding mailing-lists that is even fair i would now think, since
for example you addressed the mailing-list, if that distributes it
further to people you do not even know about, that is not exactly
forwarding.
("Forwarding" is, i would say, what is broken after one hop if
SPF is taken by the word, ie, if i send to your address but this
effectively is nothing but an alias that is then forwarded to
another email name/address, and if on the same box.)
And if only RFC 9057 Author: would be gracefully supported and
taken as a constant originator, then user interfaces can "take you
there", ie, were you (and i) want to be.
You know, that is so easy to do -- and anything is possible, and
done, shitting (if USA can deal with that word) anything into DNS
and email messages (it is just that all you use email clients
which do not reveal all the mess that lives in there), yet that
thing is a step too much, it seems.
Having said that, if it is really acceptable to include the entire
history of changes in that "stack" that email headers form (hihi:
yes please, i find it absurd that these things have to be numbered
given this is a stack; shall the software which processes it
number it as it reads, or what; protectionism is such a thing,
also in hindsight to email scrambling, in my humble opinion), as
an entry an the very signed DKIM record which detects the
modification, then, if user interfaces can nicely show the
messages' evolution, you know, .. ach ..!
This "diff" does not need DKIM2 of course, i could also add it to
my own little thing easily, yes, it could even be made an addition
to RFC 6376 on its own, hah!.
I only hesitate a bit because any "non-integrated email system",
and these are all those which do not completely deter, eh,
separate users from their own emails, like GMail or any other such
user interface do, do not have complete control over email
messages. You are developing a mail filter (milter) yourself.
On "the ingress side" you see the message, but then it ends up in
the mailbox of a user, and it is out of control in all aspects.
You then see i again on "the egress side". Ok i proposed and will
write a draft for a DKIM-Store: header, to be used to pass state,
aka build a bridge in between those isolated processing places.
But a user can remove it. And the question is, what to do then.
This also applies to DKIM2.
Now if the IETF starts standardizing that "disk failure" must not
loose a RFC 5321 message, it could also standardize that ingress
must store data in an equal way for some amount of time, and say,
now exaggerating, upload it to a featured (maybe thanks to XY
sponsor who has such a business here) clowd storage facility for
infinite availability to be at hands for the egress side, shall
the user act further on the message.
Sure, normally this does not happen as mailing-lists work pretty
much instantly. Only saying.
|>> DMARC's alignment requirement is an attempt at capturing the concept
|>> of legitimacy.
|>
|> It is an attempt at defining and constraining a very specific kind of
|> limited legitimacy.
|
|Yup, it is successful as it catches a good deal of cases, direct mail.
Anything "pollable" would do, this has *nothing* to do with this
73 page standard "monster". Imho: quite the opposite, it works
*even though* it is DMARC. Yes, have "you" *ever* made a survey
of that crap (sorry) that a search machine finds if a dumb user
like myself wants/needs to setup a DMARC entry? All that *i*
would allow is that simple thing called p=reject, and use the
precious DNS space for anything else but _dmarc
v=DMARC1;p=reject;sp=none;pct=100;adkim=r;aspf=r;
rua=mailto:easy48...@easydmarc.com;
ruf=mailto:easy38...@easydmarc.com;rf=afrf;ri=86400;fo=1.
Except, *maybe*, if someone *really* wants to have a fixed SPF
check, this i understand, SPF by itself is totally useless;
combine it with all sorts of checks DKIM=y/SPF=y, DKIM=n/SPF=y,
DKIM=n/SPF=n, DKIM=y/SPF=n, what do i know.
Greetings to -- oh! -- Italy.
Have a nice Sunday.
--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)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
