Dean, I started the thread with the original question, and after not hearing a suitable response from either Spamcop or someone from the networking side of Facebook, I gave up on this thread when people like Michelle started chiming in their opinion. This thread wasn't meant to be an opinion-fest, but a technical issue that definitely hampers my customers, which apparently, everyone completely lost sight of. So really, my customers, and myself are victims of Spamcop's blocking of Facebook. -S Dean Anderson wrote:
What a load of BS from the "scammer/counterfeit-antispammer" crowd, otherwise described as con-artists and frauds.
"You're not authorized to solicit bulk email on behalf of third parties: only they are"
Huh? In this case, the third party (the user) authorized sending the mail on //their// behalf to //their// contacts. This email doesn't go out except by action of the user. The *recipients* of the email have indeed solicited email from the user; they are the contacts of the user.
Basically, what the (well-known) con-artists are trying to say is that Facebook can't be authorized by its own user to send email from the user to the contacts of that user. Finally, Linkedin, plaxo and other social networking sites do the same thing. ISPs also send email on behalf of their users, and have done so for many years.
Last, just imagine if each of your contacts had to authorize which ISP you could use to send them email. Facebook is just an ISP in the email transaction, offering a service to the user; so that the user can send email to their contacts. Obviously both the user and Facebook benefit, but there is nothing wrong with that. Its not spam because its sent at the request of the user to people the user is already in contact with.
Blocking facebook is a scam; an effort to shakedown Facebook for money/services/etc.
Jim: Are you starting to see a pattern, yet? There is no point in arguing with con-artists.
--Dean
On Thu, 4 Mar 2010, Rich Kulawiec wrote:
If I leave all boxes checked to send mail/notices/app requests to everyone in my list, or if I give FB my gmail password to pull all my contacts and send them an invite, its pure @ my request, sure FB is happy I do it, but it is no way spam. This is dead wrong. You're not authorized to solicit bulk email on behalf of third parties: only they are. In the absence of solicitation from
On Thu, Mar 04, 2010 at 03:16:25PM -0400, jim deleskie wrote: the *recipients*, bulk email is spam -- by definition.
---Rsk
On Thu, 2010-03-04 at 23:27 -0800, Shon Elliott wrote:
So really, my customers, and myself are victims of Spamcop's blocking of Facebook.
I forget how far back in this thread someone said: Spamcop *listed* Facebook for valid reasons according to their published listing criteria. Other people blocked it. Not Spamcop. FWIW outright blocking on a Spamcop listing is a particularly risky business; best to use a listing as an intelligence point towards a decision whether to block a given message or not. That's why Spamcop is referred to by the default SpamAssassin ruleset, but not in a big enough way to block outright. Fresh operational content: one of the reasons services like Spamcop occasionally list services like Facebook is that they don't honour 5xx responses to RCPT TO:. I'd offer some statistics but I'm concerned that the legal brigade will jump down my throat, but I suggest that anyone running a system like an academic mail platform take a look at the number of invalid recipients services like Facebook try to deliver. If they stopped doing that they'd be a long way towards better behaviour, IMO. Graeme
the legal brigade will jump down my throat, but I suggest that anyone running a system like an academic mail platform take a look at the number of invalid recipients services like Facebook try to deliver.
Out of ~1.5m emails on the 3rd, it was only 4 invalid recipients here. There was one more from a misspelling of facebook that had to be a spam probe. For @*myspace* it was 17 messages. For @*linkedin* it was 20 messages. Not too big of an issue, IMHO. Cheers, Michael Holstein Cleveland State University
On Fri, Mar 5, 2010 at 02:28, Graeme Fowler <graeme@graemef.net> wrote:
Fresh operational content: one of the reasons services like Spamcop occasionally list services like Facebook is that they don't honour 5xx responses to RCPT TO:. I'd offer some statistics but I'm concerned that the legal brigade will jump down my throat, but I suggest that anyone running a system like an academic mail platform take a look at the number of invalid recipients services like Facebook try to deliver. If they stopped doing that they'd be a long way towards better behaviour, IMO.
As long as we're going off-topic, might as well go all the way :V How long should a sender (say, Facebook) retain a database of 5xx SMTP responses? Just because jimbob@school.edu doesn't exist today, doesn't mean that James Robert Jones won't enroll in the fall and get jimbob@ as his school-provided email address. David Smith MVN.net
On Fri, 2010-03-05 at 09:08 -0600, David E. Smith wrote:
As long as we're going off-topic, might as well go all the way :V
Well, the conversation has continued here despite repeated mentions of mailop@mailop.org so unless the MLC deem it off-topic and squash the thread I guess it'll rumble on. My reply below, although based on email, is most definitely on-topic as it covers "good neighbo(u)r" behaviour and could just as easily apply to all manner of bits and protocols which members of this list shovel around daily. Anyway:
How long should a sender (say, Facebook) retain a database of 5xx SMTP responses? Just because jimbob@school.edu doesn't exist today, doesn't mean that James Robert Jones won't enroll in the fall and get jimbob@ as his school-provided email address.
Then that would be spam, would it not? The incoming jimbob isn't the one who left. The incoming jimbob doesn't want to hear about the old jimbob's friends "fun night out", or be invited to their stag parties, or receive discriminatory, lewd or offensive material. Context: in $dayjob we have a delay before re-using usernames. Student email addresses are never re-used, but many students use the "short" form - user@domain - of their email address to register with Facebook. [As a consequence of this problem alone, their ability to do so is being phased out] This academic year alone I have had to request Facebook strip an address from an account several times, 2 of which were for accounts which expired here over 12 months previously. In each of those cases, Facebook had been repeatedly attempting delivery of notifications/invitations and so on since the account had expired. *That's* why I mentioned it. If they had any decency they would trap those 5xx errors and do something to the account with the failing address after some period/number of failures. You know, a bit like Mailman, Sympa and other decent mailing list applications do. And yes, in at least one of the aforementioned cases the incoming recipient was clearly very upset at the emails they were receiving. So it isn't that surprising that they occasionally hit spamtraps or have complaints made against them which result in DNSBL entries. If they played nicely and observed the responses to their outgoing email stream, then it would be far less likely to happen. I guess the return question is: how long should a given operator return 5xx responses to increasing numbers of Facebook emails before trying to do something about it? Graeme
On 3/5/10 7:08 AM, David E. Smith wrote:
As long as we're going off-topic, might as well go all the way :V
How long should a sender (say, Facebook) retain a database of 5xx SMTP responses? Just because jimbob@school.edu doesn't exist today, doesn't mean that James Robert Jones won't enroll in the fall and get jimbob@ as his school-provided email address.
They really don't need to retain it at all, other than perhaps to count a few messages to determine to remove the address. A 5xx response is a permanent failure. "The specific message you are sending to this address *right now* will never be delivered, don't keep trying to send this specific message." This usually means that the address does not exist, is administratively prohibited from receiving messages, the MTA is blocking the sender, etc. It is possible but unlikely that a future message from the same sender to the same recipient will succeed. Some mail systems with "dirty word" filters may return 5xx to a specific message and allow another with different content. These aren't all that common. Things like a user going over quota or a temporary failure should not return 5xx but 4xx. Facebook (and legitimate senders of periodic subscription emails) should remove that address from their subscriber lists after receiving 5xx responses. Some subscription services will delete an address only after a series of 5XX rejects (three in a row for example) rather than just one to guard against a fluke erroneous response. If in the future jimbob@ gets assigned that address and chooses to subscribe, then it can be re-added. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
On Thu, Mar 04, 2010 at 11:27:53PM -0800, Shon Elliott wrote:
This thread wasn't meant to be an opinion-fest, but a technical issue that definitely hampers my customers, which apparently, everyone completely lost sight of. So really, my customers, and myself are victims of Spamcop's blocking of Facebook.
1. I would suggest taking this discussion to spam-l, which is where the world's leading experts on spam may be found. If you describe your problem correctly and in detail (see next point) then it's very likely that you can get the technical assistance you're seeking. 2. You're still making an anti-spam 101 level mistake here, by erroneously claiming that Spamcop blocks Facebook: Spamcop doesn't, because they can't. If *your* customers can't get mail from Facebook, then it's because something within *your* operation (presumably under the control of someone within *your* operation) is blocking it. ---Rsk
participants (6)
-
David E. Smith -
Graeme Fowler -
Jay Hennigan -
Michael Holstein -
Rich Kulawiec -
Shon Elliott