"Meng" == Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
writes:
Meng> The above seems to be a "for" vote. As recent discussions
Meng> have focused on patent issues, a positive vote is worthy of
Meng> note.
It is. Unfortunately there appears to be no procedure within the last
call for indicating approval of the drafts, other than by individually
replying to specific objections that are made, and I'm afraid that
given the volume of traffic during this last call, I'm simply unable
to keep up with the comments.
Meng> Could I ask you and other people who like Sender ID on
Meng> technical grounds to please explain what you like about it
Meng> in more detail?
One of the main reasons is that it allows me to take steps to make it
harder for people to spoof mail from domains that I control.
For me personally, this is not a serious issue. In the context of the
company I work for, however, we have concerns that spam and virus
e-mail purporting to by from us is taken at face value by
non-technical users. Phishing isn't an issue for us; customers and
potential customers thinking that we are sending them spam and viruses
is a moderate concern.
In this context, Sender ID is far more useful to us than SPF, because
SPF protects an identity that is not available to the MUA in any
reliable way. I realize that Sender ID also protects an identity that
isn't currently displayed by MUAs, but hopefully we will see that
change fairly rapidly. [1]
That said, we will almost certainly be publishing SPF records in
addition to Sender ID records. And we will almost certainly publish
Sender ID records, regardless of whether the spec has the aproval of
the IETF or gets filibustered by endless arguments in this WG, as long
as we see a benefit to us in doing so. (And Hotmail alone accounts
for a large enough proportion of non-technical users that I suspect
that even if no-one except Microsoft checks Sender ID, we would decide
that it was in our interests to publish.)
As the above implies, I'm not against checking MAIL FROM (and believe
it is useful), and I would like to see this WG discuss MAIL FROM
validation if/when it completes its current work items (Sender ID and
CSV).
Another reason is that like most people, particular people who have
been using e-mail for a long time, we are deluged with spam. We use a
heuristic spam checker, which works quite well, but there is a need to
whitelist organizations in order to avoid false positives. The
problem is that when you whitelist a major corporation, the chances of
receiving spam or viruses claiming to be from is quite high. So I'd
like to be able to whitelist based on a validated identity. For this
purpose though it doesn't really matter what the identity is. If they
publish Sender ID records, I'll whitelist them based on the PRA; if
they publish SPF records, I'll whitelist them based on the MAIL FROM.
If they publish CSV records, I could whitelist them based on HELO
strings (though this last requires them to tell me all the HELO strings
of their outbound MTAs, so is less convenient).
I support Sender ID also for the flexibility of the SPF record. Many
people have criticised it for being over-flexible (and hence over
complex, and overly resource intensive) but I feel that this
flexibility is key. Having a policy language that is expressive
enough to allow people to describe their existing policies will result
in far more buy in than requiring people to change their policies to
fit in with MARID.
It is certainly possible that we may need to make per-user exceptions
in the records we publish, at least in the early days of deployment,
to allow for a small number of people who work from home who don't
currently use our MTAs to originate e-mail.
I am of course aware of the utility of a validated identify in
constructing reputation systems, and the potential utility of
reputation systems in attacking the spam problem. Sender ID is likely
to be useful in this regard, too. This is an area though where I'm
less sure of relative utility of the different identities, and I can
see that CSV may be of particular use here too.
However in summary, of all the proposals I'm aware of, Sender ID seems
to me to be of the most immediate utility to me. This is partly due
to its specific functionality, and partly due to the specs now being
in a fairly mature state, which could be deployed tomorrow without too
much difficulty. (Without a doubt, SPF is the most mature of the
specifications out there, but for the technical reasons I describe
above, I expect Sender ID to provide me with greater benefits).
Even if Sender ID is incompatible with the GPL [2] -- and I'm
skeptical that it is except under the most extreme interpretations --
Sender ID can be implemented now, and the license is not so burdonsome
as to prevent significant deployment. If it can't be implemented
within some MTAs, it can be implemented as a separate stand-alone
package that interfaces to the MTA. Most modern MTAs have interfaces
that would permit this.
I have nothing against this WG seeking other solutions which are
either better or complementary to Sender ID, including attempting to
design an alternative solution that is unencumbered by patent claims.
But that should be a future work item.
Despite any technical and legal shortcomings of Sender ID, it's the
best thing we have _now_, and I am in favour of progressing it to the
IESG for consideration as a Proposed Standard.
Sorry for the length of this
-roy
[1] If Microsoft fixes Hotmail, Outlook and Outlook Express to display
the PRA, and Apple fixes their mail client to display the PRA, and
both Microsoft and Apple roll out the fixes via their automatic
updates mechanisms, then you've covered a very significant proportion
of non-technical users. There's no reason why this has to take lots
of time.
[2] And on further reflection my opinion is that whilst Sender ID
_might_ be incompatible with the GPL, to conclude this you have to
take a fairly extreme view of what the GPL requires. In particular,
under such a view, _no_ GPL'd software that has (or even might have)
any patent claims against it may be redistributed. That essentially
means prety much all non-trivial GPL'd software. For instance, the
Linux kernel is GPL'd, and we _know_ that there are numerous patent
claims that may apply to it. Distributing an MTA that incorporates
Sender ID is at least as legal is distributing the Linux kernel. If
that's not good enough, then maybe it's time to throw away the GPL.