> On 6 May 2025, at 10:53 PM, Aditya Garg <gargaditya08@xxxxxxxx> wrote: > > > >> On 06/05/25 10:41 pm, Junio C Hamano wrote: >> Aditya Garg <gargaditya08@xxxxxxxx> writes: >> >>> I think we can add a minimal check to ensure that there are no two dots together. >>> Does that sound fair? >> >> Is it a common misconfiguration in the first place that singling out >> a name ending with double dots (which indeed is very likely that >> nobody should be relying on getting accepted by sensible SMTP >> servers, hence very safe tightening) is worth doing? If MacBooks as >> shipped would by default claim to be "MacBook.." like your example >> had (I do not know if that is the case, as I do not live in Apple >> ecosystem), it may give us a reason to special case the trailing >> double-dots, for example. > > Its not an Apple thing. I am not even using macOS at the first place > when I tested this, I was on Ubuntu running on my Mac. > > Its a problem with Net::Domain. In systems without a domainname, and > without a period in the hostname, Net::Domain will always output > "hostname..". You probably should check your machine with smtp-debug? > Btw, the output of `hostname -f` on these machines will be "hostname". > > Now gmail does not reject this, probably the reason it is unnoticed? > Since Outlook support is new, such problems are being observed. > > >> >> I personally feel that "run of at most 63 alnum or dash separated by >> a single dot in between" is easy enough to explain, so if I were >> doing this change, I would just use the regexp used in posted patch >> [*] and if nobody complains, stop right there. If we get any >> complaint, then I'd detect and reject the case where the string ends >> with double-dots. > > The regexp used in the original patch covers the double dots case as well. > Its basically following the RFC guidelines, which a sensible SMTP server > should follow, and so must a user. > >> >> [Footnote] >> >> * ... but I don't know if your use of negative lookaround >> assersions is correct. Shouldn't the "a label cannot begin or >> end with dash" be applied not just to the first label but >> consistently to all of the dot-separated labels? > > I think you are talking about this case: > > someone.-example.com > > No, its not valid.a Although my regex is considering it as valid, which I can fix, but I'd rather wait for us to come to a conclusion on how we are fixing this in the first place.