Re: [Jmap] Submission

["Adrien de Croy" <[e-mail]>]

------ Original Message ------
From: "John Levine" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 22/04/2017 3:32:46 AM
Subject: Re: [Jmap] Submission

>In article <em470cf3b9-5af0-4eb9-a7d0-1d6273df597a@bodybag> you write:
>>I think trying to pass through SMTP extensions when there may not even
>>be an upstream SMTP server is going to be problematic let alone ugly.
>
>It seems very likely that there will be a submission server, if there
>is any hope of sending mail to the billion people who use SMTP mail
>now.

sure, but conversely there very often will not be.  Intra-organizational 
mail for example is often not forwarded with SMTP.

Also if we don't prevent it, inter-organizational mail could use this as 
well.  The key is to not make that impossible or worthless.

SMTP is just not being fixed.  Until the IETF decides enough is enough, 
and agents acting on behalf of humans must no longer do things 
anonymously (and this means using certificates at any point mail is 
injected into the system so that these can be revoked on abuse), we will 
continue to be inundated with spam, with all the down-stream impact that 
has on the usefulness of electronic mail.

Just because there is a cost to doing something, doesn't necessarily 
mean that cost would not be well-spent.  There's an ongoing cost of 
leaving things the same as well.

All costs are very difficult to quantify, and therefore it's very 
difficult to determine which path we should take on a purely cost-basis.

But we could also consider maybe that if we actually came up with a 
design which was compelling enough, then adoption could make it 
worth-while.  People are sick of the problems with SMTP, and sick of the 
lack of progress addressing them.  We should be learning from things 
like Facebook messaging.

Good anti-spam is masking the issue, which is still growing, but the 
situation is actually insane.  How many legitimate mails are you missing 
out on because of the constant deluge of spam?

>
>
>>Which extensions do we think are even in scope for this?
>
>All of them.  A more interesting question is which ones are likely to
>be useful in this context.  A quick look suggests 8BITMIME, SUBMITTER,
>DSN, DELIVERBY, FUTURERELEASE, SMTPUTF8, CONPERM, MT-PRIORITY, RRVS,
>and maybe BURL.
>
>R's,
>John
>
>PS:
>
>>Sounds like DKIM didn't think through the need to transform mail. ...
>
>How about if you read the dkim list archives and get back to us on 
>that?

I'm sure it was contentious.  Just saying it seems a bit silly to define 
a system that requires mail to not be transformed, and then layer it 
over a transport that may need to transform mail.  Just sayin'

Adrien


>
>
>_______________________________________________
>Jmap mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/jmap