From: Jim Youll <jim(_at_)media(_dot_)mit(_dot_)edu>
...
How many protocols do we have that - at the application layer - send
back the whole request when things don't work out? Imagine if you
were to abort an FTP upload and got a copy of the whole file back "so
you know which one failed"!
If you used FTP as much as you use mail and if your FTP commands
could take 5 days to fail, that would not sound so silly.
In other words, I suspect you never used UUCP for copying files.
You're saying that sender must
.. send enough messages to ONE recipient
.. in the interval between the first transmission and the first return
.. in a setting where *some* of the messages are rejected and *some*
are accepted
.. and the messages are so similar in character that the defective
Yes.
ones can't be discerned from a headers-only response message
(including the Subject: line) ... (e.g. if I send a 400mb attachment
that's rejected as "too large" I betcha I could figure it out from an
error response and time stamp)
Your seem to be assuming your situation is universal. I bet we could
find someone who sends enough 400 MByte attachments that they could
not identify a bounce from only the headers added by their MUA. I'd
ask people sending lab data or various graphics artists whether they're
careful about using unique subject lines.
Consider your traffic to this mailing list. If you got a bounce next
week from calcite.rhyolite.com, how would you know which of the "courtesy
copies" you've sent me bounced? Subject: lines would be useless. If
your MUA generates Date: or Message-ID: lines and logs them in your
"outbox," you could figure it out, but could your grandmother?
The more I think about this business of returning e-mails to the
_apparent_ sender, the more completely wrong it seems. It is an
anachronism and we should be considering putting an end to this
practice.
Fine! I agree should be a better way. Put an end to the mess.
Even I can sketch some obvious protocol bits what would do the technical
part of the job. But you must accept the whole job and not just the
easy, netnews sidewalk superintendent parts of the job.
The easiest part of your job is figuring out and documenting the
protocol that will let a compliant MUA do the right thing when it
receives your new concise DSN. It's also easy to look at the message
to decide whether to do an old or new and concise bounce.
You must also modify 3 or 4 MTAs (e.g. sendmail, exim, smtpd) to
generate the new DSN. You'll need to fix 2 or 3 MUAs (e.g. Mozilla
and Outlook) to understand them. But that's not the hard part.
An important but not hard part of the job is letting people at the
source of the message diagnose the problem. People who've spent years
trying to guess why a distant machine run by idiots who can't look at
their own logs or do their own tests is intermittently rejecting mail
have more sympathy for the current, ad hoc, brute force, bandwidth
wasting, theoretically spammer exploitable scheme.
The hard part is getting a few 1,000,000 SMTP servers to install your
MTA patches and a few 100,000,000 people to install your new MUAs,
and to deal with the transition.
My point is that this mailing list, like most anti-spam efforts, has
an awful lot of sidewalk supervising.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg