Re: [PATCH] git-send-email: Add --no-validate-email option

[Junio C Hamano <gitster@pobox.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2022-06-20 at 00:44:27, Stewart Smith wrote:
>> The perl Email::Valid module gets things right, but this may not always
>> be what you want, as can be seen in
>> https://bugzilla.redhat.com/show_bug.cgi?id=2046203
>
> You should explain this in the body of the message, since we generally
> want to know the rationale behind the change even if RedHat moves away
> from Bugzilla in the future.
>
> You could say something like this:
>
>   The Perl Email::Valid module correctly checks whether an email address
>   is syntactically valid.  However, in some cases, people have email
>   addresses which are not syntactically valid, such as those where the
>   local-part is more than 64 octets, and would like to use those
>   addresses despite that fact.
>
>> So, add a --validate-email (default, current behavior) and
>> the inverse --no-validate-email option to be able to skip the check
>> while still having the Email::Valid perl module installed.
>> 
>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2046203
>
> I don't believe we generally include Fixes headers for external bugs.

All good comments; I have nothing to add here.

>> +	# Email::Valid isn't always correct, so support a way to bypass
>> +	# See https://bugzilla.redhat.com/show_bug.cgi?id=2046203
>
> Email::Valid is in fact correct.  However, the email which you want to
> use doesn't conform to the RFC and isn't valid.  So this should probably
> say something like, "Allow people to use an email address which is not
> valid according to the RFCs if the server accepts it."

I had exactly the same reaction.  Again, I have nothing to add here.

Thanks.

>
> I think this patch would be fine as it stands with those changes. Unlike
> Ævar, I don't think we should get rid of Email::Valid, just like I don't
> think we should get rid of the transfer encoding checks.  I support
> warning people before sending invalid emails, especially since I believe
> the address in question would not be deliverable through some mail
> servers (such as mine).