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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

[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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux