[SC-Help] Re: Getting balcklisted

[Spam Hater]

Please see my remarks in line with yours...

At 03:21 PM 1/12/2005 +0000, Iain typed:
 
>Thanks for this Mike, for the reference link and for posting this across to 
>spamcop.help...but to explain a bit more...

I'm not Mike, but I'll jump in with my opinions anyway...  :)

>First, the plans are only that Email will be sent to addresses which users 
>have explicitly provided and only content related to services they've 
>opted-in to receive will be sent to them. There's no 'buying of lists' or 
>anything like that. It's all about proper informed opt-in, so let's take all 
>that as accepted. The issue comes down to what is *really* meant by; 
>"confirmed verifiably by a unique token." So...
>
>A user comes to the Government site. They login with credentials which can 
>be used to identify them as a real-life identity, i.e. a degree of identity 
>verifcation *far* beyond that behind most list management systems. They ask 
>to be sent information by Email. It's then the degree of verification of the 
>Email address they provide being shown to belong to that user. So there's 
>options...
>
>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. 
>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.

Bzzzzt, wrong answer...  If this is the best you can do, you are setting yourself
up to be listed as a SPAM source!  People are routinely advised NOT to
click unsubscribe links in messages they receive.  This is a quick way to 
confirm your account to the SPAMmers who then sell it for more money...

>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. If the incorrect chose not 
>to immediately unsubscribe then they implcitly agree to receive further 
>mail. 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.

Again, no user should ever click a 'get me out of this' link so you are still
going to get reported as SPAM.

>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??

Same difference as above.  Whether it is going to an "SMTP sink" or a live
person who has never heard of you before, neither of them is going to click
your unsubscribe link and you may very well get reported.  Especially if the
wrong address the provided happens to be a SpamTrap address that gets
reported automatically.

>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:

Stop right there!!  This is the only way to play!  You still may get reported by
those with a hair trigger who have no idea who you are and figure it is just
run of the mill SPAM, but this is your best bet for staying off the SPAMlists.

>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. 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

Correct.

>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

If you want to be 100% certain that the email address belongs to the person
that signed up, you have no other choice.  Tell your business manager to wake
up and smell the SPAM frying...  I have joined several mailing lists that
operate in this fashion and it is not a hassle at all.  If I really want the info I
am willing to jump through a reasonable number of hoops to get it.

>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. 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

This is less likely to happen and if it does, you can easily provide the
original signup details and show that you had been sending email to that
address for N number of months successfully and without complaint.  This 
would be enough to get you off of any SPAMlists.  A preemptive approach
would be to re-verify your lists every so often with the same confirmed opt-in
approach.

>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.

4b is best practice and if you follow it, you should not have many problems.

>Hope this makes sense. Also, BTW, AOL go through their spam policy in a lot 
>of detail at http://www.aol.co.uk/about/policy/spam/senderfaq.html and 
>linked pages :-)
>
>Thanks.../Iain

You are welcome.