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

[Hector Santos <[e-mail]>]

On 12/17/2019 7:40 PM, Salz, Rich wrote:
>>     We may have to explicitly embed this clause in the protocol:
>>           A "MUST NOT" protocol element MAY be overridden with "550" Policies.
>
> Bleh. We often say "we're not the protocol police."
>
> I think it's always clear that local policy can override.
>
> Is the IETF going to come and arrest it's own website?

No. It should keep it simple - follow the standard protocol.

The bottom line is this breaks code, 37+ years of consistent protocol 
SMTP state machine logic, its not a bad vs good thing, regardless of 
the frequency of usage, regardless of scale, even the hobbyist, the 
entire community, in my long pre-internet protocol design and 
engineering world, a MUST concept is burned in, SHOULDs and MAYs are 
optional features provided to sysops/customers, your switches.

Do it this way, and the network/system homogeneous or heterogeneous, 
it all works.   Due to inconsistent application of some unknown rule, 
it broke a SMTP "standard" protocol.   In lieu of a specific black 
listing/block "trained thing," my concern this gem will most 
definitely begin to be copied and soon enough it will trap more 
clients using ip literals.

Its wrong. its that simple.  I am the OP. I filed the action item.  I 
only discovered it because the long time whitelisted mail.ietf.org 
server changed it's whitelisted ip address.  So a unsolicited mail 
sender CBV (Call Back Verification) was triggered. It failed due to 
the mail.ietf.org server violated the RFC2821 protocol. It had no 
legit reason for the rejection.

For the record, a CBV is the most effective spoof/fake reverse path 
filter method that exist.  I have 16 uses of daily statistics to prove 
it, yield 50-80% rejection rates near near-zero (hate to say none) 
false/true positive/negatives.

http://www.winserver.com/public/spamstats.wct

I will follow the cogs with this. Just do the right thing. I am doing 
whats prudent and practice for my compliant SMTP package ALWAYS. In 
fact, we filter on violations of the ip-literal mismatches. I am not 
going to reject legitimate SMTP compliant machine HELO/EHLO 
ip-literals. If my sysops and admins want to do that, thats up to them 
but its not coming from me, I am not going to encourage it because 
there is absolute no legitimate reason to do so and I think the 
mail.ietf.org admins, whoever, are wrong about this. It is unfair to 
Klensin and the mail community who work hard to get these things right.

I'm done.

--
HLS