On 11/29/2015 2:10 PM, Steve Atkins wrote:
Chris's approach is reasonable, but I fear it is premature.
The foundational issue here is a trade-off between information hiding
and information disclosure. Privacy vs. ops support.
I've seen essentially no public discussions, here or anywhere else,
about the technical aspects of this policy tradeoff.
Absent some community-based sense of the underlying technical issues
here, targeting a specification is, in my view, not ready for prime time.
There are already providers who remove or falsify Received headers in
order to protect their users, so there is also the opportunity to look at
what is currently being done and the effects of it.
As one example, Gmail is one of those providers. (They're also consistently
the biggest source of B2B spam in my inbox.)
Good point.
We are also talking about "hiding." How about conversion, gateways?
There was never any "law" that required local hosting storage formats
to remain in IETF RFC mail format. It can be a local proprietary
format once the final destination has been reached, mail "screened"
and made available for the user. Header stripping features were a
normal consideration.
What was always most important to a gateway, storage design was the
ability to communicate, reply back between heterogeneous mail systems.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp