[SpamCop.net - protecting the internet through technology]

[SC-Help] Re: Getting balcklisted

Pop nobody at spamcop.net
Fri Jan 14 12:42:31 EST 2005


>From the peanut gallery and purposely top-posted:
If you don't like it, respond to a different part of the thread; I'm not going to debate anything beyond this because it's much too long to be scrolling thru
.  
It is my considered opinion that you may have read, but did not fully comprehend, what you read.  I am a concussion victim and thus learning disabled and with memory retrieval problems, and yet I understood the response you received quite well, I think.  IMO, your response is more of a statement that you intend to do it your way regardless, as opposed to an open mind trying to get  a head around the issues in a way you can deal with them.  
   In other words, it leads me to more believe Mike's last closing paragraphs than anything else you have said.  If you don't like the answer, you don't have to follow it.  But, there ARE ways to minimize issues, and I could even argue an answer to every point you bring up, but I won't; you didn't address anything to me, and this is unsolicited advice in a sense, albeit on topic.  

Good luck

Pop



Iain wrote:
> Well the 'item being promoted' is electronic reminders from a
> Government department that tax payments are due, so even if a message
> did have 'content' - You are subscribed to receive tax reminders and
> this is to remind you your tax is now due - I defy even the most
> hardened spam reporter to consider that a message like that is
> selling or promoting something! I know Government departments now
> like to refer to taxpayers as customers, but to consider they are
> 'selling' tax to citizens really is going a bit far :-) 
> 
> No there is no list in pre-existance, this all about how to properly
> allow users to ask to receive tax information - or more likely
> notification there is information available on the web or that they
> need to submit via the 
> web - and then ensuring the mail goes to the right person. The reason
> for all the care about checking the user and wanting as best as we
> can to ensure the Email address being provided is valid, good,
> remains good and and is for the right person, is that it's to do with
> tax compliance. If someone asks to be reminded that their tax is due
> and due to a sloppy list they don't get the reminder, then we don't
> want to get into a legal situation where the person claims their
> non-compliance is because they never got the reminder. 
> 
> Now granted that SMTP isn't the most reliable way of doing things,
> but it's the nearest equivalent to a letter in the mailbox so we have
> to use it. The issue is how to try and make it as reliable as
> possible and as convenient to use. THAT is why I'm so interested in
> making sure we don't get blacklisted either by malicious action of
> someone trying to subscribe a spamtrap to an alert and why I'm so
> interested in what automated actions an ISP might take if, say, a
> block of addresses go invalid because a businesses Email is all
> suspended. You might think that a crazy scenario, but I don't want to
> be the one that explains that the reason some large number of people
> have suddenly stopped paying their tax is because the mail alert
> system has been blacklisted because I didn't think something through.
> So excuse me, I need to be very thorough...I'm not trying to sell
> "Italian Rolexs" (don't these muppets know Rolex is a Swiss company
> anyway?!)  
> 
> So if you'll bear with me, I will have more questions as I try and
> establish 'the best' solution in terms of user convenience and
> experience, avoid a major Government department becoming a spammer
> either due to inadvertent or malicous supply of Email addresses or
> other means yet ensure the 'best' means of ensuring reliable delivery
> of important information over an unreliable carrier :-)
> 
> .../Iain
> 
> 
> "Mike Easter" <MikeE at ster.invalid> wrote in message
> news:cs3mcb$qoi$1 at news.spamcop.net...
>> Iain wrote:
>>> 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!
>> 
>> There are all kinds of spam reporters.  We'll use me as an example. 
>> If I receive an item which is 'purely' confirmatory, not promoting
>> itself or its products or its purpose in any way, and whose entire
>> purpose is to tell me that my address has been entered as desirous
>> of wanting to be on that mailing list -- and, that in order for me
>> to be so subscribed then I must click this link or reply this mail,
>> else the subscription process fails -- then I do not report that as
>> spam.  That non-reportability is aided by my observation that the
>> From of the sender and the source of the confirmatory mail and other
>> elements of the header show no bogosity;  that the item was
>> 'straightup' From = source and nonabusive to any proxies.
>> 
>> OTOH, some spamcop reporters are triggerhappy and kneejerkish.  So,
>> if they get something which they don't recognize, they might spamcop
>> report it.  That is against the spamcop rules which sez to not report
>> confirmatory items.  But, your problem is that if such a spamcop
>> reporter gets your mail, their spamcop notify doesn't provide you
>> with the email address to which you sent the confirmation.  The
>> spamcop reporting process acts as an anonymizer, so you can see a
>> problem developing for your list there.
>> 
>> In addition, if a spamtrap receives your confirmatory mail, then that
>> can cause your mailing list to be named as a spamsource as well.
>> 
>>> "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'.
>> 
>> Let's be careful about not 'overinterpreting' no content -- just
>> like we must be careful about not misusing 'welcome'.  What I meant
>> by no content was no content which is promoting the item.  Some
>> mailing lists think they can send something out promoting itself and
>> be so convincing that the person they sent it to decides that they
>> want it.  What I mean is no content promoting anything, including
>> itself.  The purpose is for confirmation, not promotion.  Obviously
>> there would be enough 'content' that the person could tell that it
>> was something they had just requested.  There are many ways of doing
>> that without the item promoting itself or being an 'issue' of the
>> mailing list subscription. 
>> 
>> Let us also be careful about this welcome business.  Earlier we were
>> talking about someone being sent a subscription to something
>> welcoming them, telling them how great this item is, in order to
>> convince them to subscribe.  Or to not unsubscribe.  That would be
>> considered a 'promotional' welcome.  When I say no content, I mean
>> no promotional content.  Only confirmatory content.
>> 
>>> 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.
>> 
>> I can't comment on all of the different kinds of mail managements
>> that recipient ISPs may do.  The ideal situation would be that if
>> you emailed an invalid address that the mail would 'bounce' where
>> bounce means be permanently rejected before transmission;  ie not
>> accepted for delivery. 
>> 
>> Emailing a dead or invalid address is quite a different matter than
>> emailing a spamtrap address.
>> 
>>> 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.
>> 
>> That's a crazy scenario.  When you use your imagination like that it
>> smells like a dirty list again.
>> 
>>> 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.
>> 
>> Same crazy scenario.  Doesn't make any sense to me.
>> 
>>> 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!
>> 
>> The reason I mention 'dirty list' is because all to often when
>> someone starts 'worrying about' getting 'balcklisted' ;-) they are
>> worrying because they *have* a list and they are worried about using
>> it.  Anyone who has a list and starts worrying about it almost
>> universally has a dirty list;  that is, they don't have a proper
>> list at all;  so they don't have a list.
>> 
>> If you don't have a list, then you don't have a dirty list.  If you
>> have a list and you're worried about what might happen when you mail
>> to it, then you have a dirty list.
>> 
>> --
>> Mike Easter
>> kibitzer, not SC admin


More information about the SpamCop-Help mailing list