Re: [exim] RFC 5321, 5322

Renaud Allard wrote:
>
>
> Marc Sherman wrote:
>> Jeroen van Aart wrote:
>>> "Bounces should only be sent if the receiver knows they'll be "usefully
>>> delivered." This is code for: Don't sent bounces when your system
>>> rejects spam or virus traffic, or you'll become an Internet pariah."
>>>
>>> That sounds nice in theory. But how can you ever in a sane manner
>>> determine with reasonable certainty a bounce will be usefully delivered?
>>> If you try to make this work it makes it also more likely legitimate
>>> bounces will not be sent out. Which in turns conflicts with:
>>>
>>> "Silently discarding messages is not prohibited, but it is strongly
>>> discouraged."
>>>
>>> Or am I missing something totally obvious?
>>
>> Yes. It means, "reject spam at SMTP time, not by accepting and bouncing.
>> Only accept messages at SMTP time that you believe you can successfully
>> deliver."
>
> Hmm, yes, but that's like before, an interpretation on how you think the
> RFC means.
>
> Honestly I think this RFC still has too much MAY or SHOULD and not
> enough MUST. This will lead to problems like before.
>

Read on. It is far worse than that.

- Too many 'MUST' are in the wrong places. Are the writers totally
*oblivious* to the existence of spam, phishing, and bot farms?

Seems so.


- Too few long-standing needs have been addressed. It is close to ten
years since Courier-MTA introduced a post-data phase extension that
would allow a server to say WTTEF: "10 of those 13 will accept that
these 3 will not." Ability to check content and return a modified list
of accept/reject while still 'online' is essential - and much 'cheaper'
than playing with potentially damaging after-the-fact 'bounces'.

- It STILL stands on 7-bit ASCII in a world where the largest internet
user community can't get by with that any longer. No quick fix - but can
we *start* on one?

- If followed to the letter, it rolls-back too many needful counters to
abuse. That's not new. But we might have expected *some* progress.

Summary: It is largely a language cleanup & consolidation that's about
ten years behind reality. Instead of advancing smtp, it would set it
back. IF it were to be followed to the letter.

WALL this: Thankfully, it will not be.

Too *damned* much is at stake to piss away common sense and lessons
learned in sweat and tears.

Bill Hacker