Can AOL's "this is spam" feedback loop be abused with a single person
responding to a single message many, many times? Inquiring minds want
to know.
Eddy
No it can't be abused [by the average AOL user] - when you click the "Report Spam" button the message disappears from your mailbox. I tested this from within AOL version 10.3 for Mac OS X.
It's too bad that about 1/3 of the reported mails are valid opt-in lists.
Ahh well -- this is a nice mechanism that AOL provides, IMO.
Matt Taber
Network Admin
WMIS Internet - www.wmis.net
Proof that any network management or security or anti-spam scheme that implies
end users with functional neurons is doomed from the get-go.
It's too bad that about 1/3 of the reported mails are valid opt-in lists.
The other 1/3rd are actual spam, but legitimately forwarded as the user requested from a personal or business domain to an AOL account. Any server in the path gets tagged as a spam source.
And the remaining third seems to be just plain old normal personal correspondence ... which I find weird.
Ahh well -- this is a nice mechanism that AOL provides, IMO.
Agreed, though maybe they should look at SpamAssasin or Postini. Take their end-users out of the filtering mechanism somehow.
--chuck
It's too bad that about 1/3 of the reported mails are valid opt-in lists.
The other 1/3rd are actual spam, but legitimately forwarded as the user
requested from a personal or business domain to an AOL account. Any
server in the path gets tagged as a spam source.
Actually only the server that connected to AOL and relayed the mail into them. I have this same kind of gripe/complaint. Only for me about 2/3rds of my scomp reports are this. The other third are the below...only veeeery rarely is an actual spam reported from our system, except in the case of where we occasionally have a fraudulent signup come through and then start spamming.
And the remaining third seems to be just plain old normal personal
correspondence ... which I find weird.
This happens because, atleast in many versions I don't know about currently, DELETE and SPAM buttons were right next to eachother, causing mis-clicks.
The other 1/3rd are actual spam, but legitimately forwarded as the
user requested from a personal or business domain to an AOL account.
Any server in the path gets tagged as a spam source.Actually only the server that connected to AOL and relayed
the mail into them. I have this same kind of
gripe/complaint. Only for me about 2/3rds of my scomp
reports are this.
I see the same thing. At least 2/3rds are spam forwarded along as
described above. I have to give some credit to AOL WRT handling that
type of situation -- they're much better than MSN/Hotmail who do not
have a whitelist or feedback loop and simply stop accepting mail for 12+
hours from any server that reaches a particular spam threshhold. They
refuse to do anything about it, even after trying to explain the
situation because "It's the Symantec software that does it." Of course
that fact they're causing affected servers to get their mail queues
backed up with mail awaiting delivery to MSN/Hotmail isn't their problem
either. Grrr...
Andrew
All,
Thanks for the many on- and off-list replies. Things begin to make a
bit more sense.
We recently began hosting a list with several AOL subscribers, and this
week's complaint volume is five times what it was last week. With one
complaint per ~4 AOL subscribers (who are but 4.6% of the total list)
this time around, and _zero_ complaints from anywhere else, I thought
something was amiss. 'tis a pity AOLers can't tell "delete" from
"unsubscribe" from spam.
Time to VERPify the list and unsubscribe people mercilessly. *grumble*
On the cynical side: Has anyone considered an "inverted" blacklist --
i.e., a _destination_-based mail blocking mechanism? Rejecting mail to
parties with excessive bogus complaint rates certainly might simplify
life for those tasked with handling "abuse" incidents. 
On a more positive note: One AOL user unsubscribed correctly. I don't
mean to bash all AOLers... just the ones who are a bit... confused.
Thanks to all,
Eddy
chuck goolsbee wrote:
It's too bad that about 1/3 of the reported mails are valid opt-in lists.
The other 1/3rd are actual spam, but legitimately forwarded as the user requested from a personal or business domain to an AOL account. Any server in the path gets tagged as a spam source.
I believe one has an extra duty to be as strict as possible about accepting email to be forwarded to external parties:
Read: Setup for every usuable blocklist, including you own, which rejects email outright. And spamassassin setup to reject any reasonable low FP score threshold. And none of that "tag em all and let the user sort it out" business.
Its not legitimate to cover your eyes and forward probable garbage to someone else. You want it on your system, thats your decision. AOL blocklisting high percentage garbage senders, including those merely forwarding, is perfectly valid in my book.
To blocklist all servers in the path or just the most recent one is a local decision
Date: Thu, 24 Feb 2005 13:46:20 -0500
From: andrew2@...
I see the same thing. At least 2/3rds are spam forwarded along as
described above. I have to give some credit to AOL WRT handling that
type of situation -- they're much better than MSN/Hotmail who do not
have a whitelist or feedback loop and simply stop accepting mail for
12+ hours from any server that reaches a particular spam threshhold.
We now refuse to forward mail that's almost certainly spam. Users may
POP it, but forwarding is out.
Jared [if you're listening], care to provide an "scomp POC"-type
database on puck?
Eddy
Date: Thu, 24 Feb 2005 14:17:24 -0500
From: Joe Maimon
To blocklist all servers in the path or just the most recent one is
a local decision
Want to DoS someone? Have fun with bogus "Received:" headers in actual
junk mail. Developing heuristics to try detecting this is interesting.
It's not impossible, but it's hardly an exact science.
Eddy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joe Maimon wrote:
I believe one has an extra duty to be as strict as possible about
accepting email to be forwarded to external parties:Read: Setup for every usuable blocklist, including you own, which
rejects email outright. And spamassassin setup to reject any
reasonable low FP score threshold. And none of that "tag em all
and let the user sort it out" business.Its not legitimate to cover your eyes and forward probable garbage
to someone else. You want it on your system, thats your decision.
AOL blocklisting high percentage garbage senders, including those
merely forwarding, is perfectly valid in my book.To blocklist all servers in the path or just the most recent one is
a local decision
Now here I would disagree. These are specific requests by
individuals to forward mail to from one of their own accounts to
another one of their own accounts. I do not think AOL (or anyone)
should consider mail forwarded at the customers request as indicating
that our mail servers are sending spam.
As that is apparently not the case I have seriously considered as a
matter of policy refusing to install mail forwards to AOL customers.
Mark Radabaugh
Amplex
Date: Thu, 24 Feb 2005 14:53:14 -0500
From: Mark Radabaugh
As that is apparently not the case I have seriously considered as a
matter of policy refusing to install mail forwards to AOL customers.
Or give users a choice between filtered forward and no forward.
Eddy
Due to AOL scomp and SPF we have stopped forwarding all together. Existing accounts are grandfathered and we are working on migrating them all to IMAP-SSL. ALL new accounts have to IMAP their mail from our servers. I get WAY too much junk from forwarded mail going to AOL. I also get way too many tech support calls about forwarded mail being rejected because of SPF
-Matt
[...]
On the cynical side: Has anyone considered an "inverted" blacklist --
i.e., a _destination_-based mail blocking mechanism? Rejecting mail to
parties with excessive bogus complaint rates certainly might simplify
life for those tasked with handling "abuse" incidents.
It's interesting that you should ask that today. A few days ago
we started throwing around an idea along these lines:
- N = # of bogus abuse/spam reports for a given destination
- X = # of reports where we stop delivering mail to
a given destination
- for 0 < N < X -- deliver the mail, but also inform the sender
that the destination address has reported spam/abuse coming from
our network, and that if it continues, we won't deliver mail
to that destination anymore.
- for N > X -- tell the sender that we aren't delivering the mail
because it is likely to get us put on a blacklist.
We haven't fleshed things out completely, because we're not sure
the cure is better than the disease yet...
Very good idea, given the lack of any standard way for a receiving
ISP to know that the mail was forwarded.
Forwarded mail shouldn't be rejected as a result of SPF if your mail server is using SRS to rewrite the from addresses in the "mail from" part of the SMTP transaction of the forwarded emails... as long as your SPF record isn't messed up of course. 
Vinny Abello
Network Engineer
Server Management
vinny@tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN
"Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain
Forwarded mail shouldn't be rejected as a result of SPF if your mail server is using SRS to rewrite the from addresses in the "mail from" part of the SMTP transaction of the forwarded emails... as long as your SPF record isn't messed up of course.
I know but that just wreaks of a hack which I'm not currently willing to do. It works better for us to terminate the forwarding and sell the customer full mail service. My SPF record isn't messed up as far as I know.
-Matt
Now here I would disagree. These are specific requests by
individuals to forward mail to from one of their own accounts to
another one of their own accounts.
But a request to forward mail is not a request to facilitate
abuse by forwarding spam.
I do not think AOL (or anyone) should consider mail forwarded
at the customers request as indicating that our mail servers are sending spam.
Why not?
Did it come from your servers? On your network?
If "yes", then it's YOUR spam, and you should expect to held fully
accountable for it. If that's an unpleasant notion, and I'll stipulate
that it sure is for me, then you need to do whatever you need to do
in order to put a sock in it.
We are long past the time when excuses for relaying/forwarding/bouncing
spam were acceptable. The techniques for mitigating these -- at least
to cut down a torrent to a trickle -- are well-known, well-understood,
well-documented and readily available in a variety of implementations.
More generally, the best place to stop spam is as near its source as
possible. So if you're the forwarder, you're at least one hop closer to
the source than the place you're forwarding to -- thus you should have
a better chance than they do of stopping it. And you should at least
make a credible try: nobody expects perfection (though we certainly hope
for it) but doing _nothing_ isn't acceptable, either.
So, for instance: take advantage of the AOL feedback loop. Anything
that they're catching -- that you're not -- indicates an area where
you can improve what you're doing. Find it, figure it out, and do it.
Everyone benefits -- including all your users who aren't having their
mail forwarded.
---Rsk
No point in implementing SRS
There is however a point in asking people who persist in publishing
-all records to consider changing those to ~all or ?all, and then
telling people who treat spf hard failures as 100% sign of spam not
to.
--srs (fresh from watching a Meng Wong / Dave Crocker / Jim Fenton
panel at apricot 2005)