----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
As far as RfC 2821 is concerned: no square brackets => no IP,
and no dot => no FQDN, For 2821bis John proposed to allow a
trailing dot for cases like FQDN ai. (= TLD is also a host).
For SPF and CSV I don't see any problems with the first rule:
(square brackets) <=> (IPv4 or IPv6 or IPvFuture).
Right.
Part of the problem with integrating new DNS/domain based validation methods
is the overhead in the DNS lookup process.
In short, you will the spread of DNS results:
nxdomain
none
success (i.e., a SPF,, CSV record exist)
DNS server downtime/timeout issues
and it will be high on the NXDOMAIN, NONE side especially during the early
adoption periods. You need to consider that spammers will also remain
non-compliant until they need to adapt as well.
Basically, the idea of:
No Brackets ==> presumed DOMAIN
is not a practical idea to implement because systems will endure a very high
volume of HELO hits such as:
HELO #.#.#.#
So what I have been trying to get a focus on is the syntax field validation
considerations not only for SMTP servers adopting these new DNS proposals,
but also view them as new general SMTP related issues that may apply
regardless if a system implements one or more of the DNS-based proposals.
Here is a small set of invalid HELO/EHLO captured in the first two hours of
July 3:
00:01:43 Invalid HELO 221.209.94.61 client address [221.209.94.61]
00:01:56 Invalid HELO 213.77.14.102 client address [213.77.14.102]
00:08:02 Invalid HELO 208.247.131.9 client address [220.124.189.131]
00:14:54 Invalid HELO 208.247.131.9 client address [220.119.191.94]
00:14:55 Invalid HELO 208.247.131.9 client address [222.235.89.108]
00:14:58 Invalid HELO 208.247.131.9 client address [202.158.176.251]
00:15:07 Invalid HELO 208.247.131.9 client address [220.176.218.27]
00:38:58 Invalid HELO 218.19.207.228 client address [218.19.207.228]
00:39:49 Invalid HELO 208.247.131.9 client address [70.150.14.52]
00:46:08 Invalid HELO 61.149.132.171 client address [61.149.132.171]
00:46:15 Invalid HELO 61.149.132.171 client address [61.149.132.171]
00:46:27 Invalid HELO 61.149.132.171 client address [61.149.132.171]
00:46:35 Invalid HELO 61.149.132.171 client address [61.149.132.171]
00:46:36 Invalid HELO 61.149.132.171 client address [61.149.132.171]
00:55:01 Invalid HELO 208.247.131.9 client address [218.14.149.71]
00:55:15 Invalid HELO 208.247.131.9 client address [61.254.73.93]
00:55:20 Invalid HELO 208.247.131.9 client address [218.14.149.71]
00:55:33 Invalid HELO 208.247.131.9 client address [200.83.141.113]
01:06:03 Invalid HELO 208.247.131.9 client address [222.94.49.237]
01:06:15 Invalid HELO 208.247.131.9 client address [60.8.20.37]
01:19:02 Invalid HELO 208.247.131.9 client address [218.54.88.18]
01:19:03 Invalid HELO 208.247.131.9 client address [218.64.87.217]
01:26:16 Invalid HELO 200.63.237.123 client address [200.63.237.123]
01:27:01 Invalid HELO 211.113.209.69 client address [211.113.209.69]
01:30:00 Invalid HELO 221.220.202.183 client address [221.220.202.183]
01:30:18 Invalid HELO 221.220.203.206 client address [221.220.203.206]
01:30:41 Invalid HELO 221.220.203.206 client address [221.220.203.206]
01:30:52 Invalid HELO 221.220.203.206 client address [221.220.203.206]
01:30:56 Invalid HELO 221.220.204.74 client address [221.220.204.74]
01:31:10 Invalid HELO 221.220.203.206 client address [221.220.203.206]
01:31:25 Invalid HELO 221.220.203.206 client address [221.220.203.206]
01:31:36 Invalid HELO 221.220.204.74 client address [221.220.204.74]
01:32:05 Invalid HELO 208.247.131.9 client address [222.119.35.40]
01:32:05 Invalid HELO 221.220.204.74 client address [221.220.204.74]
01:32:21 Invalid HELO 208.247.131.9 client address [211.162.133.147]
01:33:51 Invalid HELO 208.247.131.9 client address [221.159.200.48]
01:33:59 Invalid HELO 208.247.131.9 client address [219.156.250.114]
01:37:02 Invalid HELO 61.50.165.190 client address [61.50.165.190]
01:37:03 Invalid HELO 61.50.165.190 client address [61.50.165.190]
01:37:05 Invalid HELO 61.50.165.190 client address [61.50.165.190]
01:37:06 Invalid HELO 61.50.165.190 client address [61.50.165.190]
01:37:08 Invalid HELO 61.50.165.190 client address [61.50.165.190]
01:58:52 Invalid HELO 61.80.233.222 client address [61.80.233.222]
01:58:55 Invalid HELO 61.81.128.100 client address [61.81.128.100]
01:58:58 Invalid HELO 61.81.147.99 client address [61.81.147.99]
01:59:01 Invalid HELO 61.81.149.244 client address [61.81.149.244]
01:59:04 Invalid HELO 61.81.20.103 client address [61.81.20.103]
01:59:07 Invalid HELO 61.81.204.80 client address [61.81.204.80]
01:59:09 Invalid HELO 61.81.210.125 client address [61.81.210.125]
01:59:32 Invalid HELO 61.81.25.137 client address [61.81.25.137]
01:59:35 Invalid HELO 61.81.36.176 client address [61.81.36.176]
01:59:38 Invalid HELO 61.82.113.120 client address [61.82.113.120]
01:59:44 Invalid HELO 61.82.250.148 client address [61.82.250.148]
01:59:46 Invalid HELO 61.82.250.86 client address [61.82.250.86]
01:59:49 Invalid HELO 61.82.6.209 client address [61.82.6.209]
01:59:52 Invalid HELO 61.83.224.123 client address [61.83.224.123]
01:59:55 Invalid HELO 61.83.29.215 client address [61.83.29.215]
01:59:57 Invalid HELO 61.83.79.205 client address [61.83.79.205]
If you use the No Bracket == DOMAIN rule, this would produce a high DNS
lookup overhead when you implement a DNS-based proposal.
I don't believe this has anything to do with semantics. A SMTP system
designed to address today's needs can benefit by having rather logical and
simple syntax field validation considerations.
Hope this explains it better.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com