Hi,

On Wed, 26 Feb 2003 17:38:59 -0800 Marc Perkel <[EMAIL PROTECTED]> wrote:

> It's not a matter of personal opinion. EFF newsletter is not spam 
> period.

If one defines spam as 'unsolicited bulk email' and EFF does not confirm
subscription requests, then it very possible that the newsletter is
being delivered to people who have not requested it, and hence it's
spam. Period.

> You have to sign up to get it

Correction: You, or someone claiming to be you, have to sign up to get it.

Yes, to sign up, you have to fork over a lot of demographic info on a
web form and the city/state needs match the zip code, but it's trivial
to automate a web agent to mass-subscribe people to yor newsletter.
Would you like me to write some proof-of-concept code?

convoluted web sign-up process != subscription confirmation system

> - and each newsletter contains 
> unsubscribe information that is simple and works. Therefore - if Razor 
> is listing it as spam - it's either a flaw in razor - being misreported 
> or gamed by a third party - or someone who is feeding bad information to 
> razor through a bad system of reporting what is spam.

Or EFF is sending bulk mail to people who didn't specifically ask for
it, and those people are correctly reporting it as spam.

> EFF's newsletter is not being sent to people who don't request it.

Given that (as you've said), EFF's newsletter subscription process is
unconfirmed, you cannot say this conclusively.

> If is were - then bring those people forward and show me where it's
> happening so that we can remove them from the database. If you can't -
> then you can't claim that that is the reason.

Please do not try to shift the cost of administering your list to the
Razor maintainers. It is your responsibility to confirm and reconfirm
your list membership, not Razor's.

We (tinw) are claiming that it is more likely that people are receiving
your newsletter in error and reporting it as spam than it is that people
have requested to receive it and are reporting it in error. The error is
more likely in the sending, not the reporting.

Also, it's a tad offensive and ironic to get that kind of demand for
personal information from the EFF. If the Razor database maintainers
demanded the EFFector subscriber list so they could find who was abusing
Razor, I suspect the EFF would also not be so forthcoming.

> One of the issues I have a real problem with is that there doesn't seem 
> to be any way for anyone to determine how something got labeled as spam 
> so that the problem can be fixed. There needs to be some accountability 
> in the system.

Suggest a means of maintaining accountability without violating
individual Razor users' privacy. I have not been on this list long
enough to know if other properly-confirmed mailing lists have had
problems with malicious false reporting, but it would appear that the
current trust system works. An accountability system as you describe
would be a target for retailiatory action by spammers without providing
any substantial benefits to Razor users.

> I don't know what a honeypot account is. How does that relate to EFF?

I'm guessing 'honeypot account'is another name for spamtrap. One plants
email addresses of accounts that don't in a website, etc. exist so
harvesting agents will scoop them up and send mail to them. Mail hitting
these accounts is unsolicited by definition and can be safely reported
in an automated fashion.

Sometimes these addresses are hidden from casual view (e.g. in HTML
comments, white-on-white text, contentless links like '<a
href="mailto:[EMAIL PROTECTED]"></a>'.) Sometimes they
are blatantly obvious (a big link like '<a
href="mailto:[EMAIL PROTECTED]">please do not feed this
spamtrap</a>'.) Some people use dead accounts of ex-users, and
ex-employees. Others scan their mail logs for delivery attempts to
nonexistent accounts and use those.

Here's where I beat the dead horse of list confirmation and
reconfirmation again. If you send a confirmation request (a note the
user needs to manually reply to verify their consent and address in
order to start/continue receiving list traffic) to a spamtrap, it will
not respond, and your list will not get delivered to that address, and
it will not be reported as spam. If you send list traffic to that
address, your list will be reported as spam. It's pretty simple.

Now, the question is how your list would get directed to a spam trap. Look at 
http://action.eff.org/subscribe/

There is one and only one box to enter an email address. All it takes is
one typo by a user and an admin that uses non-existant accounts as
spamtraps and your mailing list is reported as spam. There's no malice
on anyone's part here; just a simple typographical error. Your first
line of defense is having the user enter their address twice, comparing
the two, and emitting an error if the two entries differ. Slightly
irritating for the web coder and the end user but not insurmountable.
It's absolutely necessary if you want the list to get to its intended
recipient.

Next you absolutely must confirm the subscription request. From the
Mailman documentation
(http://staff.imsa.edu/~ckolar/mailman/mailman-administration-v2.html):

"Confirm: when a subscription request is made a message will be sent
back to the address being added. The new member will have to reply to
the message (without having to modify anything) for their subscription
to become active. This prevents someone from maliciously adding people
against their will."

Again, somewhat irritating to the end-user and to the list operator, but
absolutely vital if you want to have any confidence at all that your
mail is sent only to those that requested it.

Let me repeat three important points:

1. EFFector has a convoluted sign-up process but has no subscription
confirmation system. The two are not equivalent.

2. Without subscription confirmation and periodic reconfirmation, it is
possible (and I believe, very likely) that, through malice or
happenstance, EFFector is being delivered to people who did not request
it or to addresses that are not expected to receive mail.

3. Sites that use dormant or nonexistent mail addresses as spamtraps will
report EFFector as spam should EFFector be delivered to those addresses.

Fix 1) to drastically reduce the likelihood of 2) and 3) otherwise you
are wasting your time and everyone else's time arguing about Razor's
trust model. It is less likely that someone is actively trying to
supress your viewpoint and far more likely that sites are dropping your
traffic because of your poor mailing list management practices.

<rant>
Like Topica, and the DMA, the EFF seems to willfully disregard the vital
importance of confirming subscriptions. It seems to consider spam to be
what other people do, when, if we remove all content from their mail,
all the components that could be construed as 'speech', we find it's all
the same abusive, irresponsible behavior. It also seems that when this
is pointed out, these points are ignored and the doddering straw man of
Free Speech is wheeled out. Spam has nothing at all to do with what you
say and everything about how you say it and until you fix your mailing
list management practices your list is going to be rightly reported as
spam, that is, unsolicited bulk email. Trying to shift responsibility to
Razor is disingenuous; you have shown us no compelling arguments or
evidence that Razor is being used as a censorship tool or that it is
significantly abusable as one.
</rant>

I apologize if I sound a bit patronizing or redundant, but I don't know
how else to rephrase 'you must confirm your list subscriptions initially
and periodically' so that you will understand it.

I'm sorry this isn't the answer you want to hear.

-- Bob


-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Razor-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/razor-users

Reply via email to