Junio C Hamano <gits...@pobox.com> writes: > Thomas Adam <tho...@xteddy.org> writes: > >> Trying to come up with a reinvention of regexps for email addresses is asking >> for trouble, not to mention a crappy rod for your own back. Don't do that. >> This is why people use Mail::Address. >> >> https://metacpan.org/pod/distribution/MailTools/lib/Mail/Address.pod > > Now we are coming back to cc907506 ("send-email: don't use > Mail::Address, even if available", 2017-08-23). It argues > > * Having this optional Mail::Address makes it tempting to anwser "please > install Mail::Address" to users instead of fixing our own code. We've > reached the stage where bugs in our parser should be fixed, not worked > around. > > but if it costs us maintaining our substitute that much, it seems to > me that depending on Mail::Address is not just tempting but may be a > sensible way forward. > > Was there any reason why Mail::Address was _inadequate_? I know we > had trouble with random garbage that are *not* addresses people put > on the in-body CC: trailer in the past, but I do not recall if they > are something Mail::Address would give worse result and we need our > workaround (hence our own substitute), or Mail::Address would handle > them just fine.
Ping? So have we come to a consensus about the best solution here? I'm perfectly happy to send a reversion patch because to be honest hacking on a bunch of perl to handle special mail cases is not my idea of fun spare time hacking ;-) I guess the full solution is to make Mail::Address a hard dependency? -- Alex Bennée
