Hector Santos wrote:
In a similar vain, you have DSN there for the bounce stuff. Again, this
is a specific way of doing a bounce, yet not everyone uses this specific
RFC to do a bounce. It is relatively recent and not required for
operations. So technically, in a similar argument for generality, it
should not be there.
Yes. Not all DSNs are non-delivery-reports (NDRs), and not all NDRs
use the form specified in the DSN RFCs. Because "bounces" are extremely
critical for anything in the email architecture I'd draw exactly the
opposite of your conclusion: Using SIEVE as a synonym for "filtering"
might be okay (if it doesn't cover the sending of unnecessary NDRs).
But using DSNs instead of NDRs could muddy the waters for other auto-
replies (including solicited DSNs, MDNs, and RFC 3864 auto-replies).
On the other hand RFC 2821 chapter 3.7 has a clear SHOULD about using
the DSN format for NDRs, so _maybe_ the abstraction in the I-D works.
Maybe, I haven't checked it yet (for the new draft), and never thought
about checking it before, thanks for pointing it out.
[SIEVE]
you are talking about a specific, cryptic computer language, that
just so happens to be a RFC, hence a "formal standard" document, but
nevertheless it is not the "common standard" used for mail filtering
across the board.
It's a set of RFCs, and AFAIK the only set of RFCs addressing "mail
filtering". Stuff like DNSBLs, SPF, and DKIM would be certainly too
specific for an "architecture" I-D. Maybe the OPES stuff would fit,
but IMO it's also too specific: What mail receivers do between their
MX and their MDA is their own business, otherwise the I-D would also
have to address LMTP, SASL, IMAP, and what else.
the DSN acronym is generic enough for every system to understand
that it is a bounce processor.
It makes me very nervous that I don't consider "DSN" as an acronym
for "bounces". "Delivery status" also covers solicited "all went
well so far" messages, IMO in the direction of "message tracking",
and another set of RFCs.
the problem is that we don't have a "pseudo" industry understanding
for the acronym MFA
Or MON, MRN, ADMD, ... The "ADMD" thingy is IMO worse than SIEVE,
because it's already far too detailed, unlike MON and MRN.
changing it to MFA and defining MFA would be more technically
appropriate in my book.
Inventing new acronyms out of thin air would be dubious, if you hate
"SIEVE" (5 characters) then "filter" (6 characters) could also do it.
And of course the definition of "filter" would then need a reference
to the SIEVE RFCs. As the only example of RFCs in this direction,
ignoring all more specialized RFCs about DNSBLs (only an I-D at the
moment), SPF, DKIM, etc.
Frank