Hi Frank,
At 07:50 16-01-2008, Frank Ellermann wrote:
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.
2821bis does not deal with verification of return paths (Section
3.6.2). It does mention SPF. :-)
The dilemma in 2821bis is "local site policy" which means that you
are in a better position to determine what is right for your environment.
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.
I think that the mail-arch draft is better placed for that as it aims
at giving an overall view of the architecture.
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.
You may be right but it still won't be right unless the other
participants agree with your point of view.
Regards,
-sm