ietf-smtp
[Top] [All Lists]

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

2019-12-17 22:23:51
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



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