Re: [PATCH] git-send-email: Add --no-validate-email option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 30, 2022, 21:03 UTC
- Message-ID
- <xmqqzghtdftx.fsf@gitster.g>
- In-Reply-To
- <220630.868rpee6d3.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 13 quoted lines
> I'm suggesting that we replace our own validation with that of the SMTP > server's, yes they're don't 1=1 correspond, but I think the part of the > Venn diagram of where that matters is too small to worry about. > > It has the advantage of side-stepping issues with not having > Email::Valid, as well as those cases where we're being overzelous about > RFC validation, but our local SMTP is willing to try to deliver the > mail. > > It's not like authors of MTAs haven't heard of that character limit, but > they're also aware that that certain parts of the spec are loosely > enforced, and that trying delivery is often better than rejecting a mail > out of RFC pedantry.
I am not sure if that is a healthy direction to go.
If a local outbound relay is written with the knowledge that it will never be talking to the SMTP at the final mailbox directly, I would expect that it may not implement any validation at all, relying on the "next hop" smarthost to reject anything invalid it throws at it.
So...