"SM" <[EMAIL PROTECTED]> 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.
