Hi.
(top post)
I won't use language nearly as strong as Rich's even if I might have
at least some of the same feelings. However, there is another point
that seems to have gotten lost in the noise. Writing with my hat as
editor of RFC 5321 and draft-ietf-emailcore-rfc5321bis (the latter
should be in IETF LC soon) on but without necessarily speaking for
anyone else...
As far as the broader Internet community is concerned, the main
output of the IETF is standards track documents that are supposed to
be produced to make the Internet work better. As part of that
process, we often spend considerable energy discussing requirements,
including, in BCP14, the differences between MUST, SHOULD, MAY, etc.
Independent of what providers the LLC selects to process out mail, if
messages are sent out with ietf.org sender addresses that violate
MUST-level provisions of RFCs 5321 or 5322 or other email specs, the
clear signal to anyone who notices is that, regardless of what BCP 14
says, the definition of "MUST" and "MUST NOT" includes "unless we
find it operationally or commercially inconvenient.
The IETF is in an almost unique position in that regard. If some
ordinary enterprise (or even Amazon or Google) decides to ignore
requirements in our standards, those standards are voluntary and that
really is a commercial decision regardless of what Rich or others
might think of it. But if we do so in obvious ways --in this case,
in email we are sending out-- that calls the credibility and
integrity of our standards into question.
Now, I have not done enough analysis to know whether the bad behavior
Rich describes extends to things that are required by email
standards. Lack of response to 2142 service addresses probably does
not count because the spec uses words like "encourage" and because it
imposes no requirements if the organization does not implement the
associated service although it would be in better taste to reject
messages for unsupported addresses rather than accepting and then
ignoring them. In any event, if a message is sent out by
SomeUser@xxxxxxxx, my reading of RFC 2142 is that the obligation to
maintain those addresses belongs to the IETF, not Amazon SES. On the
other hand, were Amazon SES to ignore the RFC 5321 requirement about
the insertion of "Received:" headers containing FROM clauses as one
of their competitors does, that would, IMO, be a serious problem if
the IETF were using them to send out messages from IETF addresses and
domains.
john'
--On Thursday, July 25, 2024 09:27 -0400 Rich Kulawiec <rsk@xxxxxxx>
wrote:
> On Tue, Jul 02, 2024 at 12:24:51PM +0100, Jay Daley wrote:
>> For now at least then, we are going to continue with the plan to
>> move to Amazon SES for mail sending.
>
> I commented on this off-list, but on reflection, decided to send
> something on-list as well.
>
> This is a terrible idea. Amazon SES is one of the worst (large)
> email operations around: a persistent source of abuse and attacks,
> and unresponsive to messages sent to RFC 2142 role addresses. It's
> a sewer, and it has been for a long time. (It rivals
> googlegroups.com and onmicrosoft.com for incompetence and
> negligence.)
>
> The irony is that an enormously wealthy entity like Amazon could
> easily afford to staff it with an adequate number of people who are
> properly trained and who understand their professional
> responsibilities to the entire rest of the Internet. Amazon
> *could* make it an exemplar for everyone else to learn from and
> follow, and that'd be great; but instead they've chosen to let it
> be overrun and misused.
>
> There is no way that IETF should lower itself to working with this
> garbage fire of an operation.
>
> ---rsk
>
