Vernon Schryver wrote:
From: "Chris Lewis" <clewis(_at_)nortelnetworks(_dot_)com>
Our rejection messages are pretty explicit: "this email was blocked by
Three problems:
1) A few MTAs manage not to show these messages to the sender AT ALL.
They just get a generic "it didn't work".
2) Many MTAs bury these strings so deep in bafflegab about NDRs/X.400
gunk and other sillyness (like listing each MX and retry in
excrutiatingly useless detail), that it's very easy to miss the message.
3) Language.
Here's an idea: extend RFC2821 to mandate a series of response codes
that MTAs can interpret and display to the senders.
Eg, some sort of SMTP policy return error:
55x <RFC2821 extended code> <policyflag> <how to get it fixed>
That does nothing at all for your first two problems. It also does
nothing for the third problem without a whole other system that does
not exist on all platforms and that in any case would require a lot
of new code in MTAs.
You missed one of guiding principles. That the extended return
convention be specifically designed to be human readable, and at the
same time easy to machine parse.
Our experience has been that even when the person receiving our bounce
doesn't understand english prose, there's enough hints in it that they
can usually react properly. Abuse desks in China often don't understand
a word of english. But a forwarded email with the word "spam" in the
subject is pretty obvious...
As is our experience - I get a significant fraction of FP reports with
non-english text, or even non-8-bit character sets. I still manage to
figure out what the problem is and fix it. Even if they don't
understand my reply.
With a standard convention for doing this, even people who don't
recognize english meanings at all can learn (from their friends if
necessary) how to react since it'd be consistent across bounces from all
systems generating the conventions.
In essence, with zero MTA support, the situation is no worse than it is
now. It provides for extended functionality when it becomes available.
Because it would. Not having it doesn't cripple email or cause more
bounces (as trying to deploy a stamp/signature system would). Having a
compliant MTA simply makes it easier to decipher the bounces you'd get
anyways. A painless deployment, and trivial/no brainer to implement for
the next iteration of MTAs.
MTA bounce "presentation" has always been an overlooked area. It's time
that someone paid a little attention to it and did some useful things -
at least at a BCP level.
That other system is required to translate the
extended codes into "localized" natural language.
Perhaps I shouldn't have phrased it that way. It'd be _more_ than
adequate to simply generate text consistent with the language that the
MTA is already configured to generate (ie: all of our reported FPs that
contain MTA bounce notices in French. Or Arabic. Or even in unicode).
Leave true "sender language" generation for those willing to go that
extra mile with their "Language-Preference" headers and other gunk. Nice
feature, but not required.
However, the fact that fancy response codes wouldn't help your three
problems is not the worst. Worse is that it is yet another solution
that depends on deploying extended policyflag decoding software in
10,000,000 MTAs.
Doesn't require that at all. I could do it _now_ with our mailers
without anyone anywhere parsing the results, and it'd still work fine.
100% backwards compatible.
But wait, there's still more. In 35 years I've been in the software
trade, I've seen a lot of "error code" systems. *ALL* of them are
the same at the end. Sometimes the translation from a number (e.g.
"ABEND 1234" or "killed signal 10") to a string (e.g. "bad pointer")
is automatic and sometimes is manually finding the number in a list of
numbers and strings. In either case, you get a general message that
is meaningless except to the high priests of the system.
But it doesn't need to be. All it is is a protocol "escape" to
something with more power to explain exactly what happened.
If you got:
550 x.y.z NOSPAM http://foo.bar.blat?reason=XYZ
I don't expect or even want the user to be able to instantly say
"ohmygosh my proxy is open!", and go off and try to "fix" something -
anything.
All I want is the user to click on the link (or cut-and-paste it into a
browser).
Or, if it says:
550 x.y.z NOSPAM FORWARDBOUNCE
mailto:spamhandler(_at_)mydomain(_dot_)org?subject=XYZ
simply send email to the address.
The idea is to get the user to "call" something that can do a much
better job of explaining what's going on, using routine, every-day,
current web (or human beings behind a mailbox etc) practise.
The best and only working solution is to do as SMTP does. That is to
include numbers that some software might but probably won't understand
as well as English for humans. The English can be tailored for special
cases such as including a telephone number. In special cases it can
be a language other than English.
This is "doing as SMTP does". It's simply providing an additional
machine-readable convention for better interpretation of the message the
rejecting MTA is trying to communicate in an ordinary SMTP response
code. It's a lot easier for the sending MTA than the rejecting MTA to
get closer to a language other than english - it's already configured
that way. But it ain't hard to make the convention human readable.
There's less than a dozen different meanings you're trying to convey anyway.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg