Steven Champeon wrote:
I'll add that even if everyone were willing to email/call with problems,
the hideous things that (e.g.) Exchange does to your carefully
handcrafted rejection errors are enough to cripple the least tech-savvy
of your likely audience, anyway.
All the more reason to advise people not to use Exchange for any Internet based communications.
Regards,
Mat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here's what one of the messages my system produces:
Apr 7 12:02:26 tongs postfix/smtpd[15229]: NOQUEUE: reject: RCPT from
mail.middreut.com[208.61.243.195]: 454 Service unavailable; Client host
[208.61.243.195] blocked using dnsbl.cagreens.org; Whoops! Please see
http://greens.org/delist and note your sending address is -->
208.61.243.195 <--. Sorry.; from=<> to=<agates@godmoma.com> proto=ESMTP
helo=<exchange.middreut.local>
This provides a reasonable explanation... as long as you can read
English. If you want to talk about hard to understand: every time I post
to nanog, I get a bounce message from someone in Germany, in German.
About as much use as my bounce message is to someone who doesn't read
English.
... and why aren't bounce messages standardized in content and formatting?!?
Thomas
James R. Cutler wrote:
Jiminy creepers, why can't people run software that implements standards
from the last frikking *millenium*??!?
1891 SMTP Service Extension for Delivery Status Notifications. K.
Moore. January 1996. (Format: TXT=65192 bytes) (Obsoleted by RFC3461)
(Status: PROPOSED STANDARD)
1892 The Multipart/Report Content Type for the Reporting of Mail
System Administrative Messages. G. Vaudreuil. January 1996. (Format:
TXT=7800 bytes) (Obsoleted by RFC3462) (Status: PROPOSED STANDARD)
1893 Enhanced Mail System Status Codes. G. Vaudreuil. January 1996.
(Format: TXT=28218 bytes) (Obsoleted by RFC3463) (Status: PROPOSED
STANDARD)
1894 An Extensible Message Format for Delivery Status Notifications.
K. Moore, G. Vaudreuil. January 1996. (Format: TXT=77462 bytes)
(Obsoleted by RFC3464) (Updated by RFC2852) (Status: PROPOSED
STANDARD)
> ...and why aren't bounce messages standardized in content and formatting?
Jiminy creepers, why can't people run software that implements standards
from the last frikking *millenium*??!?
because those are feel-good standards, with no selfishness hooks. emitting
standardized bounce messages helps the internet but does little local good.
and indeed, in the previous fracking millenium, we did well by doing good,
but this is now. my personal blackhole list has at least 20K entries in it
whose only "offense" was bouncing a joe-job back to me in non RFC 1891..1894.
the rest of the world will no doubt go on JHD'ing this pre-compliant chaff,
and eventually false-positive so much wheat that there will be no benefit to
sending any kind of error-mail, much less compliant error-mail, since it
won't be read no matter what it looks like. there's an argument to be made
that we're already in that situation. store-and-forward should be a priv'd
operation (like relay had to become), the universal message transport should
be synchronous end-to-end. any errors must be reportable in real time unless
there's a high-privilege relationship with the sender that permits queuing.
i have an unrelated question. understand that i did my time in the messaging
salt mines, i maintained a version of sendmail while eric allman was at
britton-lee, i wrote a book about sendmail with fred avolio, i started the
first e-mail reputation project and was the employer of eric ziegast when he
invented the "RBL" DNS format universally used today. in other words i think
i'm qualified to think hard thoughts about messaging.
my question is, is there a network operations e-list that's like NANOG used
to be, someplace where routers and switches and routes and packets and ones
and zeroes are discussed, and where abuse policy, economics, morality, bots,
web, e-mail, ftp, firewalls, uucp, and bitnet are considered irrelevant and
off-topic? i did my time in the messaging salt mines. i'm ready to graduate.