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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Aug 27, 2025, 00:28 UTC
Message-ID: <aK5RInMzjC6vuLv_@fruit.crustytoothpaste.net>
In-Reply-To: <20250826133936.1569-1-gargaditya08@live.com>

On 2025-08-26 at 13:39:38, Aditya Garg wrote:

Show 13 quoted lines

> 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.

[0] Even if we don't think users will use this that way, with the number of Git users, there will be a nontrivial amount of users who do. Many of them will not realize they may be causing a problem, though.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA