Hector Santos wrote:
Suggestions:
SMTP guidelines may suggest server implementations performing IP connection
filtering should provide a SMTP rejection response at the greeting,
HELO/EHLO or the RCPT TO: state points rather than passively dropping the
connection to help reduce continue attack by "dumb spammer software."
Good material for a new BCP overhauling RFC 2505. Anybody wants to
volunteer to help with this document?
Suggestion:
Obviously, the HELO/EHLO is probably the first of the most importantly state
point where technical compliance must be followed to help address the
illegal entries. There are few proposals on this subject of HELO/EHLO DNS
lookup validations.
I would like to suggest that the SMTP specs be changed to suggest that a
bracket IP address be used in all cases for all MTA clients.
This will allow for a quick non-DNS comparison against the IP connect
address. There is no need to provide a FQDN. However, it does, it must
match the connecting IP address.
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.
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 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.
However, with WCSAP implemented, Caller ID verification now provides an
even higher rejection rate, nearly making RBL obsolete. This might suggest
that the RBL databases, I am using BL.SPAMCOP.NET, is doing an excellent
job verifiable with return path validation logic.
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.
>
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?
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.
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.
Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg