Doug,
I understand the difference. I question the reason for the difference,
given that the current
MTA ".forward" mechanism and aliasing appear to stand in the way of
allowing a
straightforward SPF implementation, particularly because the "original
author" can be foreign to
the MTA doing the forwarding.
I suggest that you have your causal concerns, or power relationships, reversed.
The problem is that SPF imposes an unreasonable restriction on long-established,
highly reasonable uses of email.
In fact, this is the inherent difficulty with path registration schemes like SPF
because it requires that the 'author' authorize each path the message travels,
to each recipient. This is a variation on the theme of "source routing" and
source routing does not scale.
The only scenario that SPF works for that is stable and scalable is for highly
integrated services, where the user environment and the transfer service are
under the same control and are quite stable.
In reality, this reduces SPF to a single-hop vetting between border gateways.
For that purpose, it is massively over-engineered. (But then I am a tad biased,
since CSV <http://mipassoc.org/csv/> targets only and exactly this limited
scenario and accomplishes it much more simply.)
More generally, let me suggest that any proposal which begins by requiring that
we get rid of reasonable scenarios is a proposal that is almost certainly deeply
flawed.
I've gotten some e-mail indicating that because the .forward mechanism
predates RFC-822,
822 is about headers. 821 is about transfer. They came out in 1982. .forward
and related mechanisms predated that by some years. Whether they predated
RFC733 (19777) which was what rfc822 revised, I am not sure. I do not recall
seeing a .forward mechanism back in 77, but it could easily have already been
around.
But I'll suggest that none of this matters. The .forward facility is a) a good
idea, and b) entirely legal within all current standards.
I'd like to see an example
of why the .forward method as now implemented is better than the MUA
method of wrappering
the forwarded materials in another envelope (with "local postage"
applied, so to speak).
My note described very substantial differences between the two.
In any event, it is always a bit challenging to change a long-established
practice for a service in use by a billion people...
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg