[Top] [All Lists]

Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP

2019-12-31 11:33:35
On 12/29/2019 9:44 PM, Keith Moore wrote:
On 12/29/19 9:31 PM, John R Levine wrote:

So they're not subject to outside scrutiny.  No wonder email
delivery is so unreliable.

Aw, come on.  They have a billion users who vote with their feet if
they're unhappy.

Sure, because changing email addresses (or services, for those who
have their own domain names) is easy for everyone.

+1 and never mind among the "billions" represent a huge chunk of junk, expired addresses and sources of spam who put pressure of the rest of the community who are the majority of systems.

I don't buy the "BIG GUY" dictates so "shut up" arguments. They can help lead the way, but they also need to also compete cooperatively with the rest of the mail community, and foremost, the must not raise barriers that forces unnecessary change on others. Just because they may be looking at allowing bias in their big data directed decisions, they must be aware that fundamentally, their biased decisions does not applies across the board to everyone else.

Nothing personal but I cannot imagine why someone running a large
mail system would care what you or I thought of their filtering
scheme. They have way more data than we will ever have.

I'd be curious as to their measurement methods, but I suppose those
are also kept secret.

I don't believe bigger volume sites have anything different than anyone else except larger amounts of it. Dimensional analysis tells us we are all the same and at end of the day, SMTP wise, we are all expected to work the same at a minimum requirement level. I hope what we are trying to here is to fine tune the system with modern considerations.

What I have been trying to separate in all these years is to use deterministic filtering based on SMTP compliancy, separating it from the more administrative, sysop-defined heuristics, subjective, nondeterministic filters.

I have two SMTP compliancy-based deterministic filters:

- Machine name ip-literal matching connecting ip because SMTP tells us it is defined as the IP address of the connecting client, and

- Dynamic validation of the Reverse Path because SMTP tells us it MUST be valid for NDN purposes.

(Technically, I have a 3rd with greylisting which test the "Good client" retry expected SMTP behavior.)

I have two POLICY-based deterministic filters:

- DKIM Policy (ADSP, DMARC and ATPS)

Everything else I consider as local policy subjective filters.



ietf-smtp mailing list

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