"SM" <sm(_at_)resistor(_dot_)net> wrote:
Hi, sorry for the late answer, sometimes flame wars with
Doug on various lists and other issues eat up my time ;-)
I wouldn't read that section together with the other
sections as a license to send bounces to innocent
bystanders.
Okay, BUT... :-) 2821bis still creates the dilemma of
"drop false positive" vs. "bounce to innocent bystander"
if an unlucky receiver prematurely accepted a mail where
that's possible.
It's better not to get into a definition of border MTA
in 2821bis as each mail environment is different. We're
are discussing the protocol here and not antispam practice.
Various RFCs and drafts talk about "border MTA", and the
mail-arch draft doesn't say what it is. 2821bis would be
in an ideal position to explain it, it has all necessary
ingredients (MX and address fallback). If it can't solve
the problems it creates (or rather inherits from 1123) it
could still explain what's going on for naive postmasters.
If we change the envelope sender, the sender won't know
if the mail was not delivered.
The sender can't fix any problems between "forwarder" and
"receiver" (or next "forwarder"), the complete concept of
"forwarding to 3rd parties" is utter dubious (after 1123).
Quoting an article on the SPF discuss list with a slightly
different POV (= whose "fault" is it if forwarding doesn't
work as designed in RFC 821):
<quote>
The admin of the forwarder is not forced to support SRS,
the admin of the receiver is not forced to white list
the forwarder. They didn't *break* anything that wasn't
already broken by RFC 1123 5.3.6(a). I submitted an
erratum for this RFC, but this wasn't about 5.3.6(a).
2821bis does not acknowledge that RFC 1123 5.3.6(a) was
always broken. I think we differ from 2821bis, but if
forwarders strictly follow 2821bis they only *break*
RFC 821, and everybody knows that RFC 821 isn't up to
date. RFC 4408 claims that RFC 821 reverse routes are
"archaic", an appeal against this wording was rejected.
Unless the IESG decides that 2821bis is too important
to do it outside of a proper IETF WG we'll get what it
says at the moment:
| To expand an alias, the recipient mailer simply
| replaces the pseudo-mailbox address in the envelope
| with each of the expanded addresses in turn; the rest
| of the envelope and the message body are left unchanged.
| The message is then delivered or forwarded to each
| expanded address.
"We" know that this cannot work for the 821-architecture
after 1123 killed the reverse routes, but obviously "we"
didn't manage to convince the author of 2821bis-06 that
this is madness for addresses at 3rd parties (in another
ADMD or MRN, pick what you like best).
Frank
</quote> The "we" is of course unrelated to this list.