Re: [PATCH v3 1/3] send-mail: improve checks for valid_fqdn

From: Aditya Garg <gargaditya08@live.com>
Date: May 6, 2025, 16:50 UTC
Message-ID: <PN3PR01MB9597E09838320FF9F403D255B889A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <PN3PR01MB9597ED4DA3E781A6EFC03B9CB8892@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>

On 06/05/25 3:05 pm, Aditya Garg wrote:

Show 42 quoted lines

> 
> 
>> On 6 May 2025, at 11:08 AM, Aditya Garg <gargaditya08@live.com> wrote:
>>
>> 
>>
>>> On 6 May 2025, at 5:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> Aditya Garg <gargaditya08@live.com> writes:
>>>
>>>> Due to current implementation, I was not able to send emails from
>>>> Ubuntu.
>>>
>>> It may be that send-email did not complain, but I have a suspicion
>>> that it the above is only half truth.  We do have an ugly last-ditch
>>> fallback to claim that we are localhost.localdomain, instead of
>>> using a misconfigured maildomain name that servers would not like,
>>> but that name is a meaningless name; from the point of view of the
>>> server, if everybody uses that name, the name loses the meaning as
>>> an identifier.
>>>
>>> It is more like due to misconfiguration you couldn't send e-mails,
>>> and by tightening the condition to tell an invalid maildomain name
>>> and have the misconfigured maildomain name that is invalid replaced
>>> with "localhost.localdomain" fallback, you managed to send things
>>> out.
>>>
>>> The real fix for individual users may probably be to see how
>>> maildomain_net() and/or maildomain_mta() gives you a bogus
>>> "Macbook.." and fix _that_.  Until that gets fixed, trying to use
>>> "localhost.localdomain" fallback might be a good workaround, but
>>> that is a workaround, not a real solution, isn't it?
>>
>> I think I should dig deeper on how the domain name is being assigned.
>>
>> Maybe its time to fix another perl module after Authen::SASL?
> 
> I've noticed bug reports regarding this in Net::Domain perl library.
> Most reports seem to be not addressed. Maybe its no longer maintained?
> 
> I think we can add a minimal check to ensure that there are no two dots together.
> Does that sound fair?

I have opened a PR here to fix the Net::Domain library:

https://github.com/steve-m-hay/perl-libnet/pull/47

Although, this library is still seems quite unreliable. See:

1. https://github.com/Perl/perl5/issues/17135
2. https://github.com/glpi-project/glpi-agent/discussions/345

I really doubt the maintainer still maintains this. I have added them to the Cc though.

As far as the script is concerned,

- The script currently checks the presence of a period in the fqdn.
- At the same time, the script does NOT check whether the fqdn starts or ends with a period.
- Also, it does NOT check if 2 periods are together or not.

a fqdn without a dot at all gets accepted by my Outlook server, but the next 2 cases are a big no. I think adding checks for these cases should make sense, afterall no FQDN would have these things.