Is Sender ID Dead in the Water? - No MARID Working Group Consensus (Groklaw)

Is Sender ID Dead in the Water? - No MARID Working Group Consensus (Groklaw)

Posted Sep 10, 2004 10:29 UTC (Fri) by CJF (guest, #16403)
In reply to: Is Sender ID Dead in the Water? - No MARID Working Group Consensus (Groklaw) by erich
Parent article: Is Sender ID Dead in the Water? - No MARID Working Group Consensus (Groklaw)

> Most open source software has hooks for extensions. For example
> these "milter" things for Sendmail. Any you can always use an proxy
> providing SenderID support. So this IS doable with
> opensource.

This is a very premissive notion of "doable". Is'nt that a bit like
saying that MSWord DOC format is "doable" with "open source" because
you can access MSWord from Linux using a VNC connection to a MSWindows
machine? In which case I guess everything counts as being
"open-source doable"...

Anyway, there are many additional complications when using SenderID
with proxies... and why should we have to use proxies? In effect,
most of these authentication regimes encourage the corporatisation of
the internet; it makes it more awkward for individuals and small
organisations to run their own mail service, or to have fixed email
addresses that are independent of an upstream ISP.

> Especially you *may* insert the code. you can distribute
> it freely, no problem with the GPL. It's just people not wanting to
> distribute code they *may not run* due to a missing licence.

This is ambiguous. Lets make it clear, the SenderID terms and
conditions are not compatible with software distributed under the GPL,
even Microsoft says so in their revised FAQ (although they of course
make out that this is a problem with the GPL, not their terms), nor
with many other licences, such as AFL, OSI etc. Also, even if you
distribute your own plugin under a different licence with which it
might be compatible (e.g. BSD), you would need to obtain permission
from Microsoft to do so.

> I doubt that SenderID will do any good if it is not widely
> deployed. Especially since Spammers have apparently been the first
> to adopt to SPF and such...

Many doubt that SenderID will do any good even if it is widely
deployed. Note that it is really not that much different from SPF,
accept that it uses a different header (the "header from" rather than
"envelope from"), and comes with an algorithm for the mail client
rather than the MTA (so when deployed as in some ways it will do less
for spam that SPF, since using the RPA algorithm does not avoid the
network traffic etc associated with spam, and may actually increase
network instability due to its additional UDP traffic).

I am using the fetchmail "prior-art" version of this algorithm, and
it really does not help spot spam these days... although it can tell
me when someone is working from home...

Even if, against the odds, it does make it a tiny bit harder for
spammers, is it really worth the loss of freedom (e.g.) for
whistle-blowers, remote workers, and those that don't want an
ISP/corporate branded email address?

If you read the discussions on this, you may come to the opinion that
Microsoft really wants this just to hack around the flaws in its own
software, so it can be seen to be doing something about the
consequences of the MS zombie cloud and the insecurities in its own
mail clients. Do we really want to give up existing freedoms for
this?

I don't mean to get at you, but reading the MARID email list really
gets me irritated at how easily a bad idea can go so far when given
the appropriate kind of backing, and also how easy it is for a company
to claim ownership of something that has been developed by others in
open discussion.

---

(Log in to post comments)