Re: [Jmap] Address Validation (was Re: Submission)

[Brandon Long <[e-mail]>]

This is the second time you've asked for the SMTP status codes and enhanced
status codes, I'm very unclear what the utility of those would be, and why
we would need
to expose them to JMAP.

We very rarely care about the difference between the codes beyond
ok/temp/perm, and find that folks are fairly inconsistent about the
enhanced codes, or that the enhanced codes don't actually translate into
useful information from a user perspective.  At best they provide a
fallback for what is otherwise a long list of regexes for the error
messages themselves.

It also ties the implementation to SMTP when SMTP may not even be used, ie
local delivery on a service using JMAP may never use SMTP.  It also ties it
to SMTP when we know that we can't implement it with SMTP (due to address
scraping concerns).

One could make a better case for tying it to LDAP, for example.

Brandon

On Fri, Apr 21, 2017 at 6:02 PM, Chris Newman <[e-mail]>
wrote:

> On 20 Apr 2017, at 23:16, Adrien de Croy wrote:
>
>> In article <emd3533c0d-dc08-45c3-801c-07972858ad64@bodybag> someone
>>> 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.
>>
>
> The present model for MUA mail address validation is to authenticate to an
> IETF standard submission server, issue a MAIL FROM + RCPT TO + RSET.
> Anyway, I support adding a feature in JMAP that does the equivalent of
> performing this sequence of commands on the Submission server and returns a
> 3-digit SMTP status code, optionally SMTP enhanced status codes (see RFC
> 3463 section 3.2) and text string.
>
> This is quite extensible and I believe this specific functionality is
> in-scope of the JMAP charter as Submission (RFC 6409) is explicitly
> in-scope. Doing address validation this way is already quite powerful. For
> example, if the submission server chooses to implement the SMTP 251/551
> response codes for local users, the mail client gains the ability to prompt
> the user to correct the address book entry for that recipient.
>
> How much validation the submission server does then becomes a
> quality-of-implementation issue (and there are, of course, security/privacy
> issues). Future work would be to define additional SMTP/Submit enhanced
> status codes for additional address validation, but that's presently
> out-of-scope for the JMAP charter.
>
> The JMAP charter does not permit development of a new address validation
> mechanism and I object to development of a new incompatible validation
> mechanism on the grounds that having two mechanisms to perform the same
> function is poor design, when a full-standard mechanism to do address
> validation already exists. I support mapping the existing Submission
> validation mechanism to JMAP in a way that preserves all the semantics of
> the existing mechanism.
>
>                 - Chris
>
> _______________________________________________
> Jmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jmap
>