ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version

2019-12-23 12:00:17
On 12/23/2019 11:50 AM, Keith Moore wrote:

On Dec 23, 2019, at 11:34 AM, Hector Santos 
<hsantos=40isdg(_dot_)net(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:

I agreed and I have admitted I have a single rule for comparing the ip-literal 
with the connection IP. Mismatches are rejected.  There are some cases (MUA 
behind the NAT) where there are a FP, resolved with authentication 
requirements. I believe this test is a correct technical SMTP check compared to 
a subjective, nondeterministic conclusion  to block all ip-literals that 
technically violates SMTP.

I believe that NATs within the ipv4 network (not merely on the periphery) will 
become increasingly commonplace, for as long as there is a public ipv4 
Internet.  I also believe that the HELO/EHLO tag is really only usable for 
inclusion in Received fields and to identify the client system within its own 
environment.  So any checks on validity with respect to the server environment 
are dubious at best and may do harm to the protocol.  This applies equally to 
IP address literals and names.

I believe I can support 100% the elimination of EHLO machine identification semantics and the need to validate it and let the receiver add a trace header that records the connection IP and optional a matching PTR, I believe many, if not all, are already doing this.

But there are senders using MTAs that well known to be bad guys with constant usage of the same machine identifiers. Most don't seem to learn nor adapt because its constantly used. These will also be part of a local policy filter.

Do you believe a backward compatible ESMTP solution is possible along the lines of a connection response preempting the need to use EHLO? Afaik, ESMTP AUTH is the only protocol that required a double EHLO sequence with the idea that the 2nd one may show additional capabilities after an successful AUTH takes place.

Ok, let me throw this into the new mail filtering mix. I am sure some here will not like it, and neither did I but I had no choice. Like I said, wcSMTP is one of more aggressive filtering systems. In December 2018, I released an major update that included Geo IP Location filtering.

http://www.winserver.com/public/aup/wcGeoIp-Location-Filters.htm

The idea is simple: IF your operation, business, etc, absolutely has no expectation to be doing business or communications with particular countries, nations or regions of the world, wcSMTP can immediately filter by GeoIP Location at the connect level.

I was totally against such concepts until last year. With the massive world wide attacks we ALL are currently feeling and seeing, again, something had to be done. It was a huge gain for many of our operators. Its has a year and the only adjustments were a few adjustments to the filter database now shared with our network of sysops and a few of our FTP-only sysops turned it off for scaling reasons. A major plus in our constant battle against foreign attacks.

Thanks

--
HLS


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>