In <E1BGZ1U-0006Ix-Up(_at_)argon(_dot_)connect(_dot_)org(_dot_)uk> "Jon Kyme"
<jrk(_at_)merseymail(_dot_)com> writes:
Meng Weng Wong>
If the MARID information is going to be used for 2822 authentication [...]
then we should at least provide a well-defined
algorithm for all receivers to apply.
I believe this is exactly what's been proposed.
The only MARID proposal for RFC2822 has been C-ID. For many of the
important case, domain owners need to use the directOnly option. The
C-ID spec basically says "everyone is on their own about how to verify
things in this case." There is no well defined algorithm.
If the algorithm we come up with
is subject to gaming by spammers, we should admit that LMAP and 2822
just don't go together.
I might buy that (if true). So where do you show that it is?
All that you need to do if you are a phisher/spammer to get around
C-ID is to put a domain that doesn't publish the C-ID stuff in a
Resent-* header. Then, for the vast majority of email users, there
will be no indication that From: header is bad. It is *trivial* for
spammers to game C-ID. C-ID will do little to nothing to stop
spammers, and yet cause email forwarders, mailing list operators and
anyone else that uses the Sender: header to have to do a lot of work.
But given that the algorithm is yet to be defined, I don't see how we can
find fault with it at this time.
Well, for me, that is a HUGE problem. Yes, we are supposed to be
discussing identities right now, but we *have* to look far more than
one step ahead. Before we accept an identity, we should not only have
a very good idea of what the algorithm should be, but we should have a
good idea of how spammers/phishers will react and adapt. Yeah, we
should also have a good idea about the semantics and even the syntax.
So far, we have people saying "I want to verify the RFC2822 data,
therefore we should include it as an identity", without giving a good
explanation of how. Well, just because I happen to *REALLY REALLY*
want to be able to validate the RFC2822 doesn't mean that I will
overlook the fact that there hasn't been a good algorithm presented.
In contrast to the RFC2822 situation, all of the LMAP proposals on the
RFC2821 identities are really very similar. There are many small
differences between the proposals, and I think that even these small
differences will take a while to come to a rough consensus, but
fundamentally, they all do the same thing.
We can be pretty certain that we aren't overlooking any obvious and
important details because RFC2821 validation is going on today with
millions of emails being checked.
With RFC2821, we can easily get lots of live data about questions like
"how many legitimate emails have envelop-from that won't pass
validation?". We can explore this question from many different angles
and split hairs to a fine degree.
In contrast, the my second message to Harry Katz, I asked:
Do you have any working code that validates the RFC2822 that we
can look at, test, analyze and collect data with? I realize that
the C-ID doc on the microsoft website has an algorithm outline,
but that would require a lot of work to turn into working code.
If you can't provide working code, can you provide data and your
own analysis of the situation?
So far, I've been providing more actual data and analysis of the data
than anyone except Lars Ingebrigtsen (of gmane.org). We can't even
answer very simple questions like "how many legitimate emails have
Sender: headers that won't pass validation?"
Again, just because you, and I, and everyone else *WANTS* to validate
the RFC2822 data doesn't mean we can, or that this WG should, work on
it first. Ignorance may be bliss, but we must not go blissfully
publishing an RFC based on our wants and hopes.
Until such time that there is at least a proof-of-concept code that we
can all play with and collect real data on real email feeds, I will
strongly object to including the RFC2822 identities as something we
should work on.
Without working code, we are just being a debating club.
</rant>
-wayne