On Thu, Aug 10, 2000 at 11:29:28PM +0000, Peter Schneider-Kamp wrote: > Thomas Wouters wrote: > > If this is for helo() and ehlo(), screw it. No sane mailer, technician or > > abuse desk employee pays any attention what so ever to the HELO message, > > except possibly for debugging. > Well, there are some MTAs (like Postfix) that seem to care. Postfix has > an option called "reject_non_fqdn_hostname" with the following description: > """ > Reject the request when the hostname in the client HELO (EHLO) command is not in > fully-qualified domain form, as required by the RFC. The non_fqdn_reject_code > specifies the response code to rejected requests (default: 504).""" > The submittor of the bug which was addressed by the patch I checked in had > a problem with mailman and a postfix program that seemed to have this option > turned on. Fine, the patch addresses that. When the hostname passed to smtplib is "" (which is the default), it should be turned into a FQDN. I agree. However, if someone passed in a name, we do not know if they even *want* the name turned into a FQDN. In the face of ambiguity, refuse the temptation to guess. Turning on this Postfix feature (which is completely along the lines of Postfix, and I applaud Wietse(*) for supplying it ;) is a tricky decision at best. Like I said in the other email, there are a *lot* of MUAs and MTAs and other throw-away-programs-gone-commercial that don't speak proper SMTP, and don't even pretend to send a FQDN. Most Windows clients send the machine's netbios name, for crying out loud. Turning this on would break all those clients, and more. I'm not too worried about it breaking Python scripts that are explicitly setting the HELO response -- those scripts are probably doing it for a reason. To note, I haven't seen software that uses smtplib that does supply their own HELO message, except for a little script I saw that was *explicitly* setting the HELO message in order to test the SMTP server on the other end. That instance would certainly have been broken by rewriting the name into a FQDN. > > Of course, if anyone else needs a FQDN, it might be worth exposing this > > algorithm.... but smtplib doesn't seem like the proper place ;P > Agreed. Where could it go? On second though, I can't imagine anyone needing such a function outside of smtplib. FQDN's are nice for reporting URIs to the outside world, but for connecting to a certain service you simply pass the hostname you got (which can be an ipaddress) through to the OS-provided network layer. Kind of like not doing type checking on the objects passed to your function, but instead assuming it conforms to an interface and will work correctly or fail obviously when attempted to be used as an object of a certain type. So, make it an exposed function on smtplib, for those people who don't want to set the HELO message to "", but do want it to be rewritten into a FQDN. (*) Amazing how all good software came to be through Dutch people. Even Linux: if it wasn't for Tanenbaum, it wouldn't be what it is today :-) PS: I'm talking as a sysadmin for a large ISP here, not as a user-friendly library-implementor. We won't be able to turn on this postfix feature for many, many years, and I wouldn't advise anyone who expects mail to be sent from the internet to a postfix machine to enable it, either. But if your mailserver is internal-only, or with fixed entrypoints that are running reliable software, I can imagine people turning it on. It would please me no end if we could turn this on ! I spend on average an hour a day closing customer-accounts and helping them find out why their mailserver sucks. And I still discover new mailserver software and new ways for them to suck, it's really amazing ;) that-PS-was-a-bit-long-for-a-signoff-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4