Pulling a few threads together:
Greg Connor wrote:
I am a little bit uncomfortable with proposals that have an
"algorithm" to
pick the "one true identity" that needs to be validated in any given
message. Perhaps our best guess will leave out some messages to not
be
validated at all. Perhaps an algorithm will pick an identity and
validate
it (like Sender:) and the user will still be misled and think it's a
forgery. Perhaps spammers will get smart and start varying
From:/Sender:/MAIL FROM even in places where they are fairly
consistent today.
Instead of "pick and choose one identity to verify", we might instead
choose to consider each field on its own, and give the receiver some
recommendation on how to validate that one field. Then they can pick
and
choose which fields to validate. HELO, MAIL FROM, From: and Sender:
could
all be checked independently. There might be different effects,
too... the
From: field checks out OK when the message is direct from a trusted
source.
If the Sender: field checks out OK, but not the From, the user might
see a
"As relayed by imc.org" message instead of the "Direct Verified"
message.
MAIL FROM or HELO checking might not alert the user of anything, but
could
be used to reject, filter, or in some cases bypass filters if the name
is
known and trusted.
Phillip Hallam-Baker wrote:
The domain owner can't select the algorithm, only the receiver can
decide
what checks they > are going to apply. they won't know what the policy
is
until they check the domain name in an identity.
Meng Weng Wong wrote:
There's no telling what receivers will do; but the only thing
we know is that if we don't give them something specific,
they're guaranteed to do what we don't want.
If we give them a solid algorithm and emphasize "okay, this
is what we recommend, if you leave the path all bets are off"
then we have at least a fighting chance.
Then we can define sender profiles for each constituency and
tell them what changes they need to make to remain compliant,
and by when.
For example:
Dear Receivers: "here is the Caller-ID algorithm for 2822
verification".
Dear Senders: this is what you need to do.
Dear Forwarders: this is what you need to do.
Dear Mailing List providers: this is what you need to do.
A couple of points of dare I say it - agreement - I draw from these
posts:
1. I think we agree its critical that we give very clear guidance to
senders about what they need to publish and what they need to do in
order to have their mail pass a MARID test. I think that does have
implications for the methods or algorithm underlying that test, but ...
2. It may be that in some situations multiple identities will have to
be checked before making a determination about what is to be done with a
message.
3. It's up to the receiver to decide what checks to perform and what
actions to take as a result. In the first place there's too much
potential for abuse in letting the sender specify how the check gets
done. Secondly, as a practical matter, on the receiving side it mostly
comes down to code. The actions might be set by policy, but there are
going to be only a limited number of implementations in code of whatever
test we come up with. On the order of 10's I would imagine. So I don't
think we need to worry too much about wild differences in behavior as
long as the spec is clear. And I think this will be relatively
self-correcting. Routines that generate too many false positives or
false negaitves will be replaced or patched by more accurate ones.