On 06/05/25 3:05 pm, Aditya Garg wrote: > > >> On 6 May 2025, at 11:08 AM, Aditya Garg <gargaditya08@xxxxxxxx> wrote: >> >> >> >>> On 6 May 2025, at 5:19 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> >>> Aditya Garg <gargaditya08@xxxxxxxx> 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.
