[SC-Help] Re: Getting balcklisted

[Iain]

Well thanks for the thoughts. It's useful to get a number of views, hence 
why explaining the logic so all can comment.

Obviously there is no way to not send the first welcome message and this may 
go to the wrong person.

One of the concerns with the 'positive id verification' 4b solution, i.e. 
verification behind login, is that although it gives positive assusrance 
that both the mail was receive properly *and by the right person* (or at 
least someone with access the the login credentials), it also starts to run 
into phishing concerns. Sending people Email links to log into banking/tax 
services is another concern. So in the same way you say people will never 
click an unsubscribe link (you'd not click an unsubsctibe link going to 
www.irs.gov? - not that this is for the IRS, but you get my point?) then 
people might also not follow-through on an Email link that results in them 
being asked for their login credentials!

There are ways to mitigate the phishing risk (which I'll not go into here), 
but my point is, the 'obvious' best practice from an anti-spam point of view 
may not be the 'best practice' from an anti-phishing perspective. So it's 
all a balance...hence the churning of thoughts :-)

Thanks for your input.../Iain


"Spam Hater" <dkona7b02 at sneakemail.com> wrote in message 
news:mailman.61.1105545498.4572.spamcop-help at news.spamcop.net...
> 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.