Matt Sergeant wrote:
I like DNS blacklists, I really do. I think they're the right thing to do
most of the time, when they are sane lists. My one big problem with them
is bounce messages - they suck. We need a friendlier bounce message system
than "MAILER-DAEMON" messages so my mum can understand why her email
didn't get through.
This is in fact the biggest problem in handling FPs - making the return
email legible enough so that the user understands what it means.
Our rejection messages are pretty explicit: "this email was blocked by
our spam filters. If you believe this to be in error, please forward
this message, including session ID, to <whitelistedaddress>, sessionID:
123244.4444"
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>
Ie:
554 a.b.c NOUBE MAIL fp_handling(_at_)foo(_dot_)bar
or:
554 a.b.c NOUBE URL http://ourblacklist.foo.bar/lookup?ip=A.A.A.A
or:
554 a.b.c SENDERPAYS POSTAGE http://postoffice.bar.foop/?session=<magic
cookie>
Then the sending MTA has a chance to generate a much more intelligible
reject - ie: couch it in the user's own language, etc.
If we can push to make FPs less painful, then filtering becomes more
palatable with less collateral damage.
If this is standardized in an RFC, you could use it right away (it could
often be explanatory enough without any MTA support on the sender's
side) and MTAs fully understanding the return codes will get more common
with time.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg