Re: [PATCH v4] send-email: add --get-smtp-server option to fetch SMTP settings

>On 2025-08-26 at 13:39:38, Aditya Garg wrote:
>> Autoconfiguring SMTP server settings is a common feature present in many
>> email clients. In order to get the correct SMTP server settings easily,
>> this commit adds a `--get-smtp-server` option to `git send-email`. This
>> option attempts to fetch the SMTP server settings for a given email address
>> via the following steps:
>> 
>> 1. It first attempts to fetch the autoconfig file from the email
>>    provider's autoconfig URL, which is typically in the format
>>    `https://autoconfig.[domain]/mail/config-v1.1.xml?emailaddress=[email]`
>>    or `https://[domain]/.well-known/autoconfig/mail/config-v1.1.xml`
>> 
>> 2. If that fails, it tries to fetch the settings from Mozilla's ISPDB at
>>    `https://autoconfig.thunderbird.net/v1.1/[domain]`.
>
>I'm sorry I didn't ask this sooner, but it just occurred to me.  Do we
>have permission from Mozilla to embed this service into Git?
>
>The reason I ask is that sometimes software vendors embed external
>services in a way that causes excessive or unreasonable load.  For
>instance, some router manufacturers hard-coded certain NTP servers into
>their firmware in a way that polled too frequently and then effectively
>DDoSed those servers, all without asking permission first.
>
>If we embed this into Git, then it will be present on systems for a long
>time.  Some Linux distros are going up to 12 or more years for software
>lifetimes, so we should assume anything we embed here is going to be
>present on OSes for at least that long and will be used at least
>millions of times a day in a highly automated way.  Even if this only
>lasts one release, it will likely be on a nontrivial number of machines
>for at least 12, if not more, years.  (Not everyone actually upgrades
>when their OS goes EOL, unfortunately.)
>
>Is Mozilla comfortable with providing that service for that amount of
>time and having every Git installation on the planet potentially use it
>at top speed[0]?  If we haven't verified that, then we should probably
>not include this service in the code.

>
>> +sub fetch_config {
>> +	require HTTP::Tiny;
>> +	my ($url) = @_;
>> +	my $http = HTTP::Tiny->new(timeout => 10);
>
>This needs to set `verify_SSL => 1` explicitly, or we'll have a security
>vulnerability due to not verifying the certificate.  Our minimum
>supported Perl version is 5.26, which shipped with HTTP::Tiny 0.070.
>Versions before 0.083 defaulted to not verifying certificates, so we
>still need to set it explicitly.