[SC-Help] Re: Getting balcklisted

[Iain]

Thanks for this Mike, for the reference link and for posting this across to 
spamcop.help...but to explain a bit more...

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.

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.

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

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:

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

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

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

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.

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


"Mike Easter" <MikeE at ster.invalid> wrote in message 
news:cs36d0$ftq$1 at news.spamcop.net...
>> Iain wrote:
>>> I hope this is the correct group to post this to...
>
> spamcop or .help will be fine now.
>
>>> I am working with a large Government Department who want to send
>>> Email reminders to users of their online services. There's a lot of
>>> concern about users giving incorrect addresses (either deliberately
>>> or by mistake) and this leading to undeliverable mail and this being
>>> mis-identified by ISPs as spam and the Department being blacklisted.
>
> There are many many reasons to be using good list management.  Failure
> to use good mailing list management will lead to the list's mail being
> reported as spam;  such spamsources will be listed and blocked;  then
> the listed won't be getting the mail they want.  And the IP address
> won't be able to complete its regular mail to other mail recipients not
> on the mailing list.  Bad business all around.
>
>>> Personally I think the chances of this are very low, but does anyone
>>> have any general ideas on what might cause an ISP to automatically
>>> blacklist an IP address?
>
> There are many many scores of blocklists, over 150, devised by various
> means and used in various ways.  Providers use public blocklists and
> create their own blocklists as part of a comprehensive strategy against
> spam, which is a big big problem.
>
>>> There have been claims that "as few as three
>>> misaddressed Emails to AOL" can cause AOL to block an IP but that
>>> doesn't seem to be included in AOL's spam policies and would surely
>>> result in most SMTP servers in the work being blacklisted by AOL!
>
> I'm not privvy to how AOL does its blocking, but it is an adamant
> antispam place, so sending multiple unwanted mails to them would be a
> very bad idea.  I've seen blocked mail reports from AOL.  They block
> individual IPs, they block domains, they block lots of things.
>
>>> Pointers to resources such as AOL's policy would be helpful plus any
>>> ideas, views or opinions. It would be intended that every message
>>> would have a 'This message is not relevant to me/unsubscribe' link
>>> plus of course full rDNS etc. would all work.
>
> Nope;  having bad mailing list management cannot be solved by having
> unsub information.  The only people who should ever use unsub
> information is a person who subscribed in the first place.  You cannot
> send unwanted mail to someone or to a spamtrap and expect it to unsub.
> That mail will be reported as spam, you can't unsub the reporter or the
> spamtrap, and you will get listed and your mail blocked.
>
> You have to not send anyone mail which wasn't specifically requested by
> them, and from you and for the specific purpose of the list;  not some
> other purpose of some other list;  and which request was confirmed
> verifiably by a unique token.
>
> There are guidelines for the creating and management of mailing lists.
> Here's one http://www.mail-abuse.com/an_listmgntgdlines.html Guidelines
> for proper mailing list management
>
>
> -- 
> Mike Easter
> kibitzer, not SC admin
>