Meng,
MWW> I would like to suggest we keep in mind:
MWW> Where the mass majority of normal email is concerned,
MWW> forwarding is an edge case.
MWW> Failure of SenderID due to noncompliant forwarding is a
MWW> corner case.
I would like to suggest that we keep in mind:
We do not have statistics about the extent of use of forwarding
scenarios, although we do know that it is used quite a lot, by many
people and in a variety of ways.
Changing a legitimate practise that has widespread use tends to be a
good way to get the community to reject a proposal.
So, let me suggest that trying to marginalizing the problems caused
with forwarding scenarios is not such a good idea.
MWW> We should also keep in mind the positive scenario for SenderID:
Perhaps you are suggesting modifying the specification -- by the way,
are talking about marid-core? if not, then what specification are you
discussing? -- to explicitly list the scenarios for which it works
well, that is, the ones for which it is not problematic? That would be
very helpful.
MWW> The positive scenario is the scenario we are trying to enable.
Right. Unfortunately, global standards usually need to work across
the entire architecture of the service they are modifying.
MWW> I also want to point out that SUBMITTER:
MWW> - should appear rarely,
this is because you believe that rfc2821.mailfrom and
rfc2821.submitter will usually be the same?
MWW> * SUBMITTER should appear rarely.
MWW> SUBMITTER need not be used when the MAIL-FROM is identical
MWW> to the Sender. This is a very common case.
So you do not mean that the syntactic form should appear rarely, not
that the semantics of submitter-based authentication and authorization
should get used rarely?
But the semantics are the issue, not the syntax.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>