[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 server changed it's whitelisted ip address. So a unsolicited mail sender CBV (Call Back Verification) was triggered. It failed due to the 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.

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 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.


ietf-smtp mailing list