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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
