On Thu, 2005-11-17 at 19:32 +0000, Paul Howarth wrote: > On Thu, 2005-11-17 at 12:00 -0700, Craig White wrote: > > On Thu, 2005-11-17 at 10:41 -0700, kwhiskers wrote: > > > I've so far gotten 55 of their spams for the 6 messages I posted > > > last night. I simply ignore them - well, actually I have both those > > > AntiSpam UOL messages blocked in procmail with a moderately specific > > > test but also a more general from uol.com.br at the moment. > > > > > > It's hard to igore them, I'd say. > > > > > > There are so many of them that it is impossible to see the actual > > > thread one's following. > > > > > > I don't know why google/gmail isn't picking it up as spam. It is very > > > successful withthe rest of it. > > ---- > > because it is an official bounce-back error type message. > > No, it isn't. If it was a real bounce, it would go back to redhat's mail > system because the envelope sender address for list messages (which is > where bounces go) is fedora-list-bounces@xxxxxxxxxxx On a list of this > size there will be lots of bounces for each outgoing message simply as a > result of email address churn, temporarily broken mail systems etc. > > This message is a challenge to the originator of the email, which is > sent to the header sender address, hence people posting to the list are > getting them. Such challenges are widely regarded as spam, and therefore > it's reasonable to ask why why google/gmail isn't picking it up as spam. --- You're correct and I'm wrong - I forgot about all the details since I have effectively solved the issue. It is a challenge/response system. I suppose someone can ask google/gmail or whomever why they don't bounce it as spam but you'll never get a definitive answer because it doesn't meet the general application of spam control. --- > > > The problem is that someone is subscribing with a mail account, bouncing > > it to an account at uol.com.br which has severe anti-spam restrictions > > which is bombarding any sender to this list. > > s/bouncing/forwarding/ --- not always --- > > > Self defense dictates that we filter them to /dev/null using > > procmail/sieve on the server, rejects on the server or mail filters in > > your mail program. > > Yep. Rejects on the server here for any uol.com.br address. > > > Under the banner of a good offense makes a great defense, I proposed > > some type of tar pit set up by a number of fedora users and within > > minutes, the smtp servers at uol.com.br will be shut down and they will > > investigate the issue. > > But anyone clueless enough to set up a challenge-response "anti-spam" > system may be too clueless to figure out what's going on too... --- being typical American, I lack linguistic understanding of anything but English (and I suppose the Brits would have an argument about my knowledge of that language too) but looking at www.uol.com.br makes me think that they are a relatively sizable ISP in Brazil and offer this type of anti-spam as a feature to their customers (regardless of how you and I judge the concept to be flawed) and since their abuse@xxxxxxxxxx is seemingly deaf to abuses that at least one person has engaged in, the pro-active measure seems to me to be a suitable candidate for fixing the problem. Perhaps as you suggest, they would be clueless to figure out what is going on but it wouldn't take them very long to act...Each smtp server only gets so many delivery processes and if enough subscribers use smtp servers which are tar-pitted for hosts from uol.com.br with each message from fedora-list@xxxxxxxxxx it won't take but a few minutes to tie up their servers in the tar pit. This is the pro-active solution to the problem. Filtering to /dev/null is a single server solution at best. The only other pro-active measure that I can conceive of is to have all users of this list send a protest email to abuse@xxxxxxxxxx (but of course, we have no knowledge that these won't samba over to the Brazilian equivalent of /dev/null. Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
