ietf-smtp
[Top] [All Lists]

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

2019-12-16 17:16:07
On 12/16/19 5:53 PM, Michael Peddemors wrote:


Frankly, it simply points to professionalism, is the operator of the sending platform informed enough to use a proper FQDN, and often that is enough to make some operators consider email arriving as less trust worthy.

Yes, it does point to professionalism.  Is the operator of the mail service professional enough to use only valid criteria in filtering mail, or do they make arbitrary, uninformed, cargo-cult decisions about what filtering criteria to use?

I've had offers for contracts blocked by spam filters, only finding out later when it was too late to get the gig.   A single blocked message can easily cost me tens or hundreds of thousands of dollars.

I don't want to hear about "professsionalism" of people sending mail, from people who (IMO irresponsibly) promote arbitrary criteria for mail filtering.    It's not "professional" to block valid mail for arbitrary reasons.

If the sender is caught lying, that's a valid criterion for filtering mail.   If the content of the message is clearly inappropriate, that's a valid criterion.   If the SMTP is clearly a violation of the protocol specification, that might be a valid criterion.   But failure of the sender to conform to some arbitrary whim, is not a valid criterion.


In a day and age where operators already go far beyond simple configuration items (eg some refusing to consider email from a domain without SPF records as more spammy) we should 'up our game'.
No, we should call out the operators who employ bogus criteria (or at least call out the bogus criteria) because those operators are doing serious harm to the reliability of email.

Having said that, I don't think the RFC's are the right place to enforce that you NEED a FQDN yet.  Just expect it will probably end up in a spam folder or rejected, without a white list ;)

We all now pretty well universally reject all email unless the IP sending it has a PTR record, doesn't mean the RFC should say we HAVE to have a PTR to send email.  (That would probably be a better starting point).

However, once we go down that slippery slope, it will affect more and more legacy and legitimate senders.

Let the operators decide what they will and will not accept, still seems the logical conclusion.

I have yet to see a single operator that does this responsibly, except for operators who offer customers the option of no spam filtering at all.

Keith


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