HELO/EHLO
This is something that surely can be looked into, however what's the
point of the HELO command in the first place if all it will do is state
the IP address that is connecting? You know what that address is anyway.
Therefore, before recommending this, we must find out *why* was the HELO
command put in place in the first place.
For logging and the matching the IP, but legacy server misconfigurations
makes this prohibitives. read below.
RFC 2502 recommends the use of FQDN:
"When we suggest use of FQDNs rather than IP addresses this is because
FQDNs are intuitively much easier to use."
Legacy concept for TTY operations <g> We are in the high speed, high
demand automation world. Its one less lookup per million request is a
tremendous saving.
Yes, the need for HELO is probably not required, especially where EHLO is
available to provide extended capabilities.
The basic design is to use for servers to use the greeting to indentify an
ESMTP (Extended SMTP) system.
Not reliable though so system who issue an EHLO first are required to
fallback to HELO.
The SMTP specs should exploit this wonderful flexibility to the maximum
extent.
For example, make HELO optional forcing compliancy with EHLO extensions.
What I mean is that you need to give designer, software product the leverage
to offer advance security in compliance with the extended standards. The
last thing I want to happen is offer something that is NOT compliant and
have some smoe sue it for tortious interference because we stopped his email
from spamming a site. Again, I would like to stress the importance for the
"new" standards to offer technical comformity options. My GUI
configuration for the Mail server may say:
---- Extended SMTP support ----
[X] Support HELO
[X] Validate Client Domain
[X] Strict Address Literal
etc, etc. You must allow me to do this!! Not that you can't stop me from
offering and I already offer strict extended smtp options, but I take pride
in RFC compliance. Its a selling point. We don't tell me "We are 99.99%
compliant!" We have this now:
[X] Extended SMTP Authentication
[ ] Required for all connections (All users must log
in)
[ ] MAIL FROM must be local domain (Intranets, closed)
Anyway, once upon a time, we use the HELO/EHLO client doman for DNS lookups
to validate the IP against the connection IP. Technically, I believe the
specs says this is want the desire was, however, legacy server do not allow
this to work. Many systems use load balancing or "smart smtp" servers,
servers to receive and others to send. What we saw is that many of these
setups do not configure their DNS requires correctly, so it was very
unreliable to validate the domain. The logic was disabled.
So the suggestion is to "reinforce" the idea that server implementations may
now begin to offer strict connecting IP checking with the client domain in
the HELO/EHLO state.
I mean, look at it now when there is mismatch:
230 Hello YYYYYY, why do you call yourself XXXXXX?
whats up with that?
If the server saw something is not right, give it the power to do something
about it! <g>
Legacy clients will be handled by defined the SMTP server
implementation.
My only suggestion here is that the SMTP puts it in writing that SMTP
server
are NOT required to support old non-compliance software.
This needs to be looked into more, backwards compatability cannot be
easily ignored.
Oh I agree. I for once will offer backward compatibility. But I need to
offer strong connectivity too without someone (I will keep nameless) make a
claim my software is non-conformant and worst, allow this non-conformity be
used as evidence in a legal suit. :-)
As per my other message, many RBLs are not reliable enough and do have
false positive. My ISPs recently started using SpamCop and I received an
email from a list member via a third party that was bounced because of
that. The use of multiple RBLs or some other guidelines might be needed.
Well, in my view, RBLS are a major contributor to the spam problem. I will
say that it isn't a coincidence the that grow of spam is directly
proportional with the growth of RBL databases.
Why?
Because if I wanted to become a bulk spammer tomorrow, in just 1 hour of
operation, I can produce a list of thousands of open relays and open proxies
that are recorded in the databases. I already proven this hypothesis with
real hard core results. I downloaded the RBL database with over 2 million
or so entries and I wrote a program to double check which entires were FIXED
or still open for abuse. I found on large percentage of the blacklisted
sites were stilll open in the first 30 days of being reported. Over time
the systems were fixed, but it took awhile.
In other words, the RBL is a double-edge sword beause it also gives SPAMMER
information that would normally take weeks or more to gather in just 5
minutes!
However, I am in agreement that is everyone used it then it doesn't matter
what open relay site information is exposed. Until that happens, its a
great source of open relay sites.
So in my technical, if we can get away from RBL and similar systems, the
better! I believe the commercial RBL sites make it different to get their
databases, but the freebies one are also good.
The open relay checks works great! However, it is problematic with
YAHOO.COM which is inherently for all intent and purpose an OPEN RELAY
site!
I have my RejectOpenRelaySite option enabled in WCSAP, so sorry YAHOO,
fix
your system. Your system is NOT helping the internet email problem!
I
put more weight on an open relay site being a spam site.
As per my other message, why is this an open relay if it does not relay
email to outside domains? Plus what about domains that have "catch all"
turned on?
I think we resolved this now. Specifically YAHOO is delaying the validation
until the DATA state. Initially, I didn't think so and with your
harvesting reason, I took it that is how it was. In that mode, it is an
open relay unless it bounces the message.
Independent of performance issues, delaying validation increases the
problem.
We must remember spammers are in the volume business of selling email
addressss ! The more than can say "Hey this system accepts this address,
therefore it is valid" the better the marketing is for them when they are
selling their services to companies. They can give a flying hoot what the
content of the mail is. In the mail is accepted, that a problem.
But then again, I am not proposing that we (SMTP) get involved in the
complicated mail analysis business. All it can do is help the process using
strict technical specs.
Also, I do not think that *anyone* can afford to deny email from Yahoo,
AOL, MSN, etc. who collectively have an extremely large number of users.
They will not care that your customers are not getting their email, and
it would be *your* customers who will care.
I agree, but early on I personally announced for my own accounts to filter
all JUNO accounts. Lots of people followed suit and auto-magically spams was
reduced <g>
My only point, they have to comply like everyone else. However, right,
there is no issue now with YAHOO. They have a delayed validation which I
will add to WCSAP. Solved :-)
If there is one possible SMTP command to add to the specs, it would be
this
idea:
non-server based MTA clients (local machine clients) use:
MAIL FROM: <>
> server based MTA clients use:
>
> RETURN PATH: <>
>
> This will give server software to decide if they want to VALIDATE the
> return path or not against DNS mx records.
There is an IETF SUBMIT protocol which is recommended to be used for
local clients instead of SMTP, which makes this point moot.
do you have something I can read?
Thanks
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg