Re: [Jmap] Submission

I agree in the ambition to make a better mail experience :-) and in the principle of keeping protocols open and modular. 

Some of the main issues with the current mail experience is its lack of evidence of senders ID and delivery. 

A lot of organizations are looking into this. 

European Telecommunications Standards Institute has published a standard on Registered Electronic Mail (ETSI TS 102 640-1). 

Maybe this framework could be used to clarify the future role of JMAP e.g. does it cover the requirement of both a Sender-Message Submission Interface and Sender-Message Store Retrieval Interface. 

So… maybe prepare JMAP to help organizations go from email to registered email?

/madsh

> Den 21. apr. 2017 kl. 08.16 skrev Adrien de Croy <adrien@qbik.com>:
> 
> 
> 
> ------ Original Message ------
> From: "John Levine" <johnl@taugh.com>
> To: "jmap@ietf.org" <jmap@ietf.org>
> Cc: "adrien@qbik.com" <adrien@qbik.com>
> Sent: 21/04/2017 12:17:02 PM
> Subject: Re: [Jmap] Submission
> 
>> In article <emd3533c0d-dc08-45c3-801c-07972858ad64@bodybag> you write:
>>> I'd love to see a mail client that does at least initial validation on
>>> destination email addresses as they are added to the message, so that
>>> errors in the addresses which can be resolved at that stage (e.g.
>>> NXDOMAIN) can be raised with the email author before the mail is even
>>> submitted.
>> 
>> This is quite the can of worms.  It's easy enough to look up a domain
>> and see if it has an A or an MX, but whatever you were planning to do
>> to validate mailboxes will get you blacklisted as a listwashing
>> spammer.
> sure, I think there are fundamental issues with trying to go further than an A/MX for now, but if we built in a mechanism to verify addresses, it could be extended later, rather than being blocked off for all of eternity.
> 
> Even A/MX would have some value.  Who knows what kind of trusted mail delivery infrastructure may come out in the future, at some stage we have to fix SMTP.  Forever is a long time.
> 
> Adrien
> 
> 
>> 
>> 
>> Once again, I really do not think this is the time or place to try and
>> fix all of SMTP's faults.
>> 
>> R's,
>> John
>> 
>> _______________________________________________
>> Jmap mailing list
>> Jmap@ietf.org
>> https://www.ietf.org/mailman/listinfo/jmap
> 
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap