[SC-Help] Re: Getting balcklisted

[Mike Easter]

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