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.
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
VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows