[SC-Help] Re: Getting balcklisted

[Iain]

I don't quite follow this, and no I've not yet read the link you previous 
sent, but will be studying it carefully, believe you me! However, you 
write...

"Nope.  That's not good enough.  If I 'accidentally' receive some mailing 
from someone, it isn't my job to unsubscribe.  A great many reporters will 
always report that as spam and not unsub."

So then, the very first Email that is sent as a part of the opt-in process 
would under your comments get reported as spam if the user wasn't expecting 
it - caused by the original web user giving someone else's address for 
whatever reason? That is a no-win situation you describe as I have no way to 
test the address provided - ever - unless I send mail to it! You also write:

"The confirmation mail when someone first subscribes to something must 
contain no 'content' other than its own confirmation."

So then, if you're the recipient of a message with 'no content' sent to you 
because someone else gave your Email address as their own address, this is 
going to help you? Surely a message that explains what it is, why it is 
being sent to the person and what to do if they do/do not want it - a 
'welcome message' - is a lot better than something with 'no content'. If by 
'no content' you mean not a first in the series of the information feed, 
then that is *precisely* what I'm describing and why we're thinking of this 
as a 'welcome message' (on the basis the vast majority of sign-ups will be 
for people who want the service and give a correct address). I have not 
described a 'content message', only one explicitly related to the sign-up, 
it's purpose and what to do.

My point about addresses 'going invalid', is that just because you get an 
opt-in message does not mean the address will be good forever. It means it 
was okay and the user wanted it at that time, but the address may lapse for 
many reasons. If *the ISP* then invokes rules about mail being sent to 
invalid mail addresses you fall into that problem despite the opt-in. So, 
let's say there's a number of people all opted-in from a company and then 
for some reason that company's Email addresses get suspended, suddenly we'd 
be sending mail to multiple invalid addresses. Yes we need to process 
'invalid address' replies, but we can't do that until we get the bounces and 
we need to try all the addresses to know they're all now bad. In this 
instance the opt-in doesn't buy us any protection. I was particularly 
interested in knowledge about ISP's 'general rules' about receiving bad 
Email that might be spam - remember my point about AOL - not just users who 
want to report stuff to abuse addresses.

I also do not understand your comments about 'a dirty list' when the whole 
purpose of posting this is *precisely* to establish the best, most 
spam-protected means of allowing users to subscribe for Email notifications 
and ensuring that for whatever reason, inadvertent or malevolent, users 
cannot sign up someone else to receive Email they don't want. It is 
precisely because we're trying to ensure the list is not only clean but up 
to date we're going through this exercise!

.../Iain


"Mike Easter" <MikeE at ster.invalid> wrote in message 
news:cs3hfj$mpv$1 at news.spamcop.net...
> Iain wrote:
>> It's all about proper informed
>> opt-in, so let's take all that as accepted.
>
> We'll see.
>
>> 1. You send a welcome message (as advised when they signed up)
>> confirming their set-up of Email information and including an
>> unsubscribe link for one-click removal if for some reason they want
>> to cancel the subscription.
>
> No.  That is opt-out.  We're looking for/ discussing/ confirmation of
> having subscribed.  They shouldn't be subscribed until they have
> properly confirmed that they have subscribed.
>
>>  The idea here is that if the address is
>> someone elses, that someone else has a fast way of saying; "This is
>> nothing to do with me. I don't want to receive any information." This
>> is the best we can do at this point.
>
> Nope.  That's not good enough.  If I 'accidentally' receive some mailing
> from someone, it isn't my job to unsubscribe.  A great many reporters
> will always report that as spam and not unsub.
>
>> 2. If the user inadvertently enters someone elses address, i.e. a
>> valid address but not their own, then the incorrect recipient would
>> have an immediate 'get me out of this' link as described.
>
> Nope.  That doesn't work.  I don't think you read the link I gave you.
>
>> If the
>> incorrect chose not to immediately unsubscribe then they implcitly
>> agree to receive further mail.
>
> Nope.  No good.  That kind of list management is going to kill your
> dirty list.
>
>> That's what the welcome would say and
>> would advise they immediately use the "This has come to the wrong
>> person" link if they didn't want to continue to receive mail. In
>> addition every message sent subsequently would include such a "No
>> more mail" link. Again, this is the best we can do to allow someone
>> to remove their address.
>
> Nope.  No good.  You keep saying 'this is the best we can do' when that
> is no where near good enough.  I smell a dirty list.
>
>> 3. If the user gives us a completely wrong address or an address
>> which goes to some SMTP sink, then it's hard for us to know that
>> other than through parsing any reply back from the recipient ISP.
>> Obviously the 'unsubscribe' link can't be clicked, but I don't see
>> how we can realistically do anything but send a welcome message to
>> the address the user gives us. Or do you think differently??
>
> Yes.  I think completely differently.  We aren't even on the same page
> because you are using euphemisms which mean exactly the opposite of
> their language.  You are using the word 'welcome' to indicate a demand
> that some unwilling recipient is supposed to opt-out of getting any more
> of something they never wanted.  That's like calling a spam a 'welcome
> to my spam' message.
>
>> 4. Now point 3 above makes the case for requiring a positive; "Yes
>> thank you for the welcome Email and I confirm I want to continue
>> receiving it" reply. This would prevent a second Email being sent to
>> the same address if say it was some kind of sink (and so no
>> bounce/non-delivery report would come back) unless the positive reply
>> had been received. However, two issues:
>
> The confirmation mail when someone first subscribes to something must
> contain no 'content' other than its own confirmation.
>
>> 4a. Although we can collect a positive confirmation 'by a unique
>> token' it doesn't actually tell us that the person making that
>> positive confirmation is the same person who gave us the address.
>
> It does if it is performed correctly.  This is about email and an email
> address.  The confirmatory email is sent which requests the
> confirmation.  If the confirmation isn't received, the person isn't
> subscribed and they get nothing else.  That is confirming the
> subscription by opting in, not out.
>
>> They could have given us a correct address for some other person and
>> that other person, for whatever reason, clicked the 'I want to
>> confirm my Opt-in' link. So we have a positive opt-in, but not from
>> the right person
>
> I was speaking of emailing the confirmation.  If a person is sent a
> confirmation and they confirm, they are subscribed.  Your imagining that
> someone is going to optin to something they didn't want is far-fetched.
>
>> 4b. We could ensure that the confirmation was from the right person by
>> making the person log back into the web service to make their
>> confirmation. This ensures that the person who set up the Email also
>> has access to the 'unique token' sent in the welcome message. So this
>> is a high degree of verification, but also a high degree of nuisance
>> for the user and our business manager's want to make the Email
>> sign-up simple and quick and not to require re logins
>
> You can do it with a unique web login or you can do it with a unique
> email reply.  It can be done properly either way.
>
>> 4c. Even if we go through either a 'weak' verification (4a) or strong
>> verification (4b) exercise of confirming the Email address and opt-in
>> status, the Email address could at any point in time be deleted,
>> suspended or otherwise become invalid without us knowing. At that
>> point we would (unknowingly) continue to send Email to the
>> positiviely verified address but which was no longer valid.
>
> There's also the issue of how to handle bounces for 'no longer valid'.
>
>> At that
>> point we're pretty much in the same position as at point 2 in that
>> we'd be sending Email to an ISP to an address that didn't exist/was
>> invalid. So, if sending mail to invalid addresses is liable to get
>> the sending domain blacklisted, then we're just as lilkely to be
>> blacklisted at this point as we are at point 2. That then begs the
>> question, what do we gain from the verification steps as the
>> verification is only at a point in time and the address may become
>> invalid for any number of reasons at any time and so we're into
>> sending mail to non-existant mail addresses
>
> That sounds like some kind of lame excuse for the problems described at
> the top.  Your top part is a much bigger problem than this bottom part.
>
>> What I am therefore trying to work through - and I'm readin various
>> other sources but thought I'd ask here - is what is 'best practice'
>> and what ensure the department won't end up being blacklisted either
>> due to deliberate action by someone (deliberately giving false mail
>> addresses) or due to accidental input of an Email address or through
>> an Email address lapsing/becoming invalid at some point after being
>> verified.
>
> -- 
> Mike Easter
> kibitzer, not SC admin
>