‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 19, 2020 12:25 PM, Ashley Dixon <a...@suugaku.co.uk> wrote:

> I don't think you fully understand Grant's point. Whilst HTTP(/2) may be more
> featureful for serving web pages, it makes absolutely no sense to use for
> anything but. Protocol age absolutely is not irrelevant: SMTP has been
> ubiquitous in mail transportation for many years, and thus, every single mail
> client supports it pretty close to the RFC. Moreover, as Grant mentioned in 
> the
> previous message, it is the only reliable method of reliably transferring
> messages to and fro systems which, in most cases, differ quite vastly in every
> element except their understanding of SMTP.

there are two aspects:

(1) backwards compatibility:  sure, email is
    better if the goal is to deal with a large
    audience.  but this is not necessarily my
    goal because i don't talk to everyone.

    and for rare cases when i need to send an
    archaic email, i can just open gmail.com,
    protonmail.com, etc, and use their web gui.

(2) technically irrespective of backwards
    compatibility:  there is no doubt that a
    http/2-based mail system will be much more
    efficient than smtp's archaic format where all
    attachments are base64-ed into giant mono text
    balls.

    the only reason we're using smtp's archaic
    text base64-ed balls is pure history.

    but, fundamentally, contents of emails are in
    the same scope as of web pages.  so emails'
    contents is not alien to http/2.  the only
    reason we don't have http/2-based mail is pure
    history, and that people resist change.

> Interoperability is the entire point of protocol standardisation in the first
> place, and if you're going to suggest a revision, or complete overhaul, of a
> standard as well-understood as SMTP, you need to provide extremely compelling
> evidence which supports your proposed replacement. So far, you haven't done
> that. SMTP can be tricky and unwieldy to configure on certain (most)
> implementations, but that does not indicate a lack of features. The complete
> opposite, in fact.

but i'm not proposing a standard for "everyone".
it's about my case of using cheap vps with
untrusty admins.

so i don't "need" to present any compelling
evidence, because i don't care about the approval
of these standardization organizations.  worst
case scenario i can shove an smtp-client leg into
gmail and call it a day, and thrive with only 1
listening tcp port (for https).

in fact, if possible, even if we wanted to go as
far as changing a protocol, we better create our
own standards free from them, specially with the
likes of w3c which have absolutely no respect for
us (they slapped us with drm despite our cries,
simply because netflex/google paid enough).
currently we're being treated like sheep and get
told which disgusting protocols to use.


Reply via email to