Spamcop Blocks Facebook?

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:

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

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

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

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

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

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.