Hi,
Dňa 14. júla 2023 18:36:53 UTC používateľ Grant Taylor via mailop
<[email protected]> napísal:
>With this in mind, my opinion is that hard and fast is often better / less
>problematic in the long term.
I guess, that by "hard and fast" you mean reject early, thus in
case of SPF as response to "MAIL FROM", right?
Yes, that is big advantage of standalone SPF.
>The DMARC implementations that I use don't do the SPF nor DKIM checks
>themselves. Instead there are other independent filters that do those before
>the DMARC filter and the DMARC filter uses the results from those tests.
I was not clear enough, sorry. I tried to "repair" that by last sentence
of this section, but i see that it doesn't solved it, thus i will try to
rephrase it:
Of course, it doesn't matter when the SPF/DKIM checks are done,
if as part of DMARC or as separate checks. What i meant is, when
result is applied...
>I'm fairly certain that SPF checks significantly pre-date DMARC.
Yes
Of course, some receivers can still do SPF only, in mean no DMARC
at all (i skip all other combinations). Beside that it is (IMO indirectly)
mentioned in RFC, it is IMO common (not only in email environment)
to not implement "new" techology immediately.
Anyway, i would expect something as this in RFC:
DMARC compliant receiver MUST NOT apply standalone SPF
results, unless DMARC's policy is p=none. In case of p=none,
they SHOULD/MAY apply standalone SPF.
Beside my poor English, it will be then clear for both sides, what
receivers can do and what senders can expect... For now receiver
have freedom and sender can only guess, and that is not about
interoperability...
>There's businesses hosting their own email which only effects them and then
>there are businesses that host other people's email as a service. I think the
>two are quite different in many regards. E.g. Google does things quite
>differently for @google.com email than their Gmail product does for @gmail.com
>email. GSuite hosted email is even more different.
But they are not doing that as differently, both, the @gmail.com
and @google.com, connections are here over TLS1.3, in both
directions. I didn't inspect their settings in more depth.
>Sometimes MTAs are forced to modify messages. I usually see it when the MSA
>or upstream MTAs support 8BITMIME and downstream MTA(s) don't. Thus the last
>8BITMIME supporting MTA *MUST* convert to 7-bit messages if the sender
>utilized 8BITMIME.
IMO that modification is fully acceptable nowadays, i meant
another modifications, eg. to qualify To:/From: addresses,
add Date:/Message-ID: headers, etc.
BTW, our alphabet has 43 letters, ASCII-US was not enough for
us from start. Exim is 8bit transparent, even without asking it,
i didn't meet server requiring to ask that (except postfix requiring
to ask SMTPUTF8 due 8bit subject, but that was problem of
friend's PHP site). While i know whole story behind email's 7bit,
i do not understand why that problem still exists, but that is out
of our discussion.
regards
--
Slavko
https://www.slavino.sk/
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
