You can also combine input from Habeas and other systems to create a
scoring system. Within the consent framework, each consent system would
receive data from multiple sources and evaluate each incoming email based
on this info.
At 11:45 AM 8/12/2003, Christopher Bird wrote:
Thanks for the observation Matt.
I think there is something else lurking here which is why I started this
thread.
I have received a bunch of mail with Habeas headers in it. I may have
once subscribed to a list that is authenticated using Habeas, but I have
now received the information that I want so I don't need to get any
more. It is also possible that I never subscribed, but got added through
the chain of "you subscribed to one of our partners" links. So rather
than spend even more time researching whether I really want to be there
or not, it is simpler just to reject the messages - or at least send
them to a "maybe I will get to that later" bucket. As the "end user" I
really don't care whether something is an abuse of Habeas's policy or
not. I care that something came in that I didn't want regardless of
which authority approved it.
Underlying all of this is that ultimately I (as a proxy here for other
users) make my own choices about what will and will not be viewed by me.
My tolerance for false positives is perhaps higher than most. My
tolerance for false negatives is really low, though. Others will have
different tolerances. As analysts and designers, we have decisions to
make about where the filtering and other behaviors should lie.
Clearly an authentication scheme that is acceptable to my ISP or my
company provides some level of acceptability to me. However, even
beneath that I have my own priorites, pressures and demands - that might
differ considerably from email account to email account.
This was not intended to be a knock against Habeas's model - I think
they serve a valuable purpose as long as the integrity is maintained,
but ultimately it is not my ISP's responsibility to decide what is
filtered or made available to me. It is mine and mine only. The Habeas
markers provide me with another data point.
Solutions, IMHO, must be multi-tiered. The user is king!
Of course this is easy for me to say. I don't run an ISP that is bogged
down by massive amounts of spam. I am not constantly fighting DOS or
other nasty attacks. I don't have to constantly increase storage
capacity and band-width to deal with the flood. I am simply an email
user with several accounts and very good hygeine.
Chris
> -----Original Message-----
> From: Matt Sergeant [mailto:msergeant(_at_)messagelabs(_dot_)com]
> Sent: Tuesday, August 12, 2003 9:31 AM
> To: Christopher Bird
> Cc: asrg(_at_)ietf(_dot_)org
> Subject: Re: [Asrg] 7. Best Practices - DNSBLs - Article
>
>
> On Tuesday, Aug 12, 2003, at 14:58 Europe/London, Christopher Bird
> wrote:
>
> > It is so very kind of Habeas to identify so precisely the
> mail that I
> > don't wish to see. The information that they put in their headers
> > almost guarantee that as a busy person, I can safely (and
> > automatically) ignore
> > their authenticated messages.
> >
> > I am speaking as an individual here - in other words as the
> person who
> > has the final say in what shows up in front of my eyes, I
> can (and do)
> > now identify whole classes of mail that previously I could not.
> >
> > Thank you Habeas
>
> What on earth are you talking about?
>
> If you're so busy, don't subscribe to those mails!
>
> If the mails have Habeas headers and you didn't subscribe to receive
> them then it's a Habeas violation and should be reported. But these
> violations are (so far) few and far between.
>
> Dropping all Habeas marked email will result in false positives, and
> doesn't warrant suggestion on this list.
>
> Matt.
>
>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg