Arnt Gulbrandsen wrote: > Standards documents have to be pedantic, and there is a pedantic > difference: 821 says HELO names the client's host name, 2821 says EHLO > names the fully-qualified domain name. > OK
But, I would worry about using the EHLO data for anything significant... If you can buy a camera (for instance, using someone else's example) which can send mail using SMTP, do you: a) automatically use an address literal. This can easily be detected automatically by the camera, but is pretty useless, given that most systems will use NAT, meaning that the address detected by the camera may not be the same as the address detected by the SMTP server, so what can you do with something that says "EHLO [192.168.0.1]"? b) manually use an address literal. This would fix the above problem, but not for dynamic IP addresses c) manually use a host name. Perfect, except it needs a host name, and manually needs to be set up. That stops 99.99% of the world's population being able to use that camera. To get around that, you use SMTP submission with SASL (OK, that requires EHLO anyway, but the EHLO name is irrelevant in that case). IMV, if it is expected by the base standard that the EHLO data is to be used for anything other than logging/tracing, then these considerations and more need to be looked at carefully. If (a) above is allowed, then that effectively defeats any extra security provided by the EHLO data, as you can just use a private IP address literal. If it's not, then that causes big problems. If it's allowed in some circumstances and not others, then this needs to be documented. -- Paul Smith VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows
