ietf-asrg
[Top] [All Lists]

Re: [Asrg] Let's try something different

2003-03-08 11:13:29
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