Jump to content

Snowbat

Membera
  • Content Count

    158
  • Joined

  • Last visited

Everything posted by Snowbat

  1. Alleged spammer? I thought Don disabled their reports due to http://forum.spamcop.net/forums/index.php?showtopic=11343 Here's a sample of the boilerplate their attglobal.net division started sending in response to SpamCop reports. They closed the ticket, apparently ignoring the data provided They failed to include the SpamCop report ID in the subject or body They failed to reply to the [at]reports.spamcop.net address (reply was sent to the From address in the spam) My reply pointing out the above problems bounced with "<rm-aots-ticketing[at]ems.att.com> Permanent Failure: Other address status"
  2. Thanks guys. I've been getting the odd spam like this for a number of months but they are now increasing in frequency. [at]Wazoo SpamAssassin runs on a local box here, fed by Fetchmail and Procmail. I fixed the 2010 bug in the first week of January. I'll PM you the headers.
  3. These three trigger a "Can't parse date of spam for age detection" error. http://www.spamcop.net/sc?id=z4111146897z4...73add6448ad2e4z http://www.spamcop.net/sc?id=z4111124197z4...032128ebb6c257z http://www.spamcop.net/sc?id=z4111121636z6...4d8e9d472fcbd9z The "offending" timestamp from my provider's mail server looks fine to me and other spam from this account parses normally. The interesting thing about these (and I suspect what triggers the error) is a bogus-looking Received line where the timestamp is interspersed with email addresses and a spurious Cc: Any thoughts?
  4. Snowbat

    more unstoppable spam query

    Not in my eperience. Cert.br is an arm of the Brazilian Internet Steering Comittee, an organization created by the government of Brazil, with members from government, enterprise, and academia. http://www.cgi.br/english/index.htm I suspect the reporting address is unmonitored and just feeds their statistics database (which is unfortunately incomplete) If you need to contact a human, try here: http://www.cert.br/contact.html
  5. FWIW, I received two replies like this from attglobal.net (2010-04-15 and 2010-05-06). Bizarrely, they pulled the To addresses out of the spams and sent the replies to those, not to the 'id AT reports.spamcop.net' addresses. Mine came from attglobal.net (not .be).
  6. Snowbat

    Massive spam operation busted

    Agus mahogany gaspipe. Your ethnic slur fails - Greenwood is a British sirname, believed to be of West Yorkshire origin.
  7. Snowbat

    SC has blocked my ISP

    On outgoing mail sent by their webmail system, it appears that Cogeco does not add a 'Received' line for the originating IP . Instead they dump it in a couple of custom X headers. This causes SpamCop to identify their SMTP servers as the source of spam: From cfis...[at]cogeco.ca Fri Apr 10 10:09:56 2009 Received: from avs02.mx.********* (avs02.mx.********* [***********.146]) by **********.********* (8.11.3/***/8.11.2) with ESMTP id n3A99uk04403 for &lt;*****************************&gt;; Fri, 10 Apr 2009 10:09:56 +0100 (BST) X-Envelope-From: cfis...[at]cogeco.ca Received: from fep7.cogeco.net (smtp2.cogeco.ca [216.221.81.29]) by avs02.mx.********* (8.13.8/8.13.4) with ESMTP id n3A99s61003971 for &lt;**************************&gt;; Fri, 10 Apr 2009 10:09:55 +0100 Received: from cogeco.ca (smtp3.cogeco.ca [216.221.81.30]) by fep7.cogeco.net (Postfix) with SMTP id 7BA642FC2; Fri, 10 Apr 2009 05:09:50 -0400 (EDT) To: (Recipient List Suppressed) Sender: cfis...[at]cogeco.ca From: dennisplat...[at]yahoo.com Reply-to: dennisplat...[at]yahoo.com Subject: 2009 FREE LOTTO AWARD NOTIFICATION DEPT X-Mailer: Cogeco Webmail - complaints to ab...[at]cogeco.ca ( 75.125.163.132 - cfis...[at]cogeco.ca ) X-Originating-IP: 75.125.163.132 Date: Thu, 09 Apr 2009 21:09:50 -1200 X-Priority: 3 (Normal) Message-id: &lt;49df0cde.13c.1a0.31186[at]cogeco.ca&gt; Apparently-To: ************************** If they were to add an appropriate 'Received' line showing handoff from the originating IP, SpamCop would be able to identify the source. Yahoo add one like this: Received: from [68.37.44.123] by web111918.mail.gq1.yahoo.com via HTTP; Mon, 31 Aug 2009 17:30:54 PDT
  8. +1 Ellen added them as 'interested third parties' on a few blocks for me but she didn't know why SpamCop had stopped autoadding them. There are now many BR blocks that do not include a report to cert.br. It would be nice if that could be fixed. It was interesting (but no surprise at all) to see Oi/Telemar (sources) and hospedagemdesites/locaweb.com.br (hosts) at number 1. The former probably is in line with the size of their customer base but the latter really deserves to be 'Intercaged'. They were very slow pulling some trojan distribution sites I reported to them (some were still up last time I checked). They are happy to hit 'spam will cease' on reports of smartfarma's weekly spam runs and do squat about it. I have a pet spammer on datacorpore so I'll keep an eye on it too. Datacorpore's upstream is Brasiltelecom so I don't think that would help much. Some of Brasiltelecom's upstreams, on the other hand, have very large cluesticks!
  9. 71.166.40.26 is currently listed by bl.spamcop.net and cbl.abuseat.org, Senderbase last day magnitude 4.0, up 2135%! http://www.senderbase.org/senderbase_queri...ng=71.166.40.26 It looks to me that you have an infected machine behind 71.166.40.26 and the folks who host your email server 'mail.instraining.com' (opentransfer.com/ecommerce.com?) are using bl.spamcop.net to reject mail for relay. The Spamcop listing is less than 24 hours old and shows both spamtrap hits and user reports. http://www.spamcop.net/w3m?action=blcheck&...ip=71.166.40.26 71.166.40.26 listed in bl.spamcop.net (127.0.0.2) If there are no reports of ongoing objectionable email from this system it will be delisted automatically in approximately 19 hours. Causes of listing * System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop) * SpamCop users have reported system as a source of spam less than 10 times in the past week Listing History System has been listed for less than 24 hours.
  10. Snowbat

    Boss IP address continually blocked

    http://spamcop.net/w3m?action=checkblock;ip=66.174.92.163 You've got more problems than just SCBL - 66.174.92.163 is listed by cbl.abuseat.org and also listed in pbl.spamhaus.org as an IP address that should not send 'direct-to-mx' mail. http://www.senderbase.org/senderbase_queri...g=66.174.92.163 This IP address appears to be a Verizon Wireless/MSN address and likely either dynamically allocated or a gateway address. In other words, it is probable that the offending mail is not coming from your boss's machine but from another myvzw.com user who was allocated this address a few hours or minutes previously. Can you configure the machine to use a myvzw.com mail server or your company's mail server for outgoing mail? You could also call Verizon and ask if they can identify the customer(s) causing these listings and take appropriate action.
  11. Snowbat

    My IP is listed

    Are your gprs users sending all outgoing mail through your company's smtp server? Is your company smtp server generating this error message? The message appears to be generated by a Kerio MailServer: http://forums.kerio.com/index.php?t=msg&goto=48525
  12. 4 times over 3.8 days. Each listing lasts about 24 hours if there is no new spam seen but any new spam will reset the 24 hour timer based on the time the spam was received (the latter is why your listing jumped from 7 hours to 22 hours). The difference in HELO strings is an indication that the spam was not relayed by your mail server.
  13. Snowbat

    Cant parse head error

    I'm also seeing these %XMAILOE spams in a Gmail account but when pulled over IMAP, they only show up in the body and parsing looks fine: http://www.spamcop.net/sc?id=z1639112433z1...37144382a92e9az http://www.spamcop.net/sc?id=z1639190680zd...ab4aa0f10bf428z
  14. The error message and other details you posted certianly points to IXWebhosting using the SCBL on your mail server to reject outgoing email. User 'Chris' reports roaming employees not being able to send outbound mail through IX due to IX using the spamcop database: http://www.vistainter.com/reviews/I/ixwebhosting.com/ IX mentions SpamCop in connection with fighting spam here, though it is not clear if they are talking about responding to abuse reports from SpamCop users, using SCBL to tag incoming email, or using SCBL to reject incoming or outgoing email: http://www.ixwebhosting.com/index.php/v2/pages.manual9#q9
  15. The format of this message indicates it came from a MailMarshal server. Configuration details can be seen in this whitepaper, pages 14 and 15 show the format. The rejection message is indeed misleading. While it appears to be triggered by the sending MTA being listed in SCBL, the rejection message fails to show the listed IP address, and worse, it leads the reader to believe their *email* address is listed by SpamCop. Someone from SpamCop should contact MailMarshal and encourage them to fix these misleading reject messages. It was warranted by the *recipient* of your mail. The recipient (or their mail provider) declined to receive your mail because their mail system is configured to do DNSBL lookups and a lookup on the IP address of your computer (or the mail server you're sending through) showed it was listed in the SpamCop blocklist. Their server, their rules. The rejection message also shows "User unknown" so even if not rejected for the SpamCop listing, it would likely be rejected because there is currently no user xxx at yyy.sg (typo? Obsolete address?)
  16. Snowbat

    [Resolved] SpamCop spamtraps

    If a malicious user can predict the confirmation URL (by having signed up previously and seeing an abusable format), it is trivial to confirm requests sent to other addresses. I once demonstrated this to a mailing list owner who swore blind his confirmation system was secure but his list was hitting spamtraps - I don't recall the exact flaw but it was either his system used the same token for each confirmation request or it used a serial counter that incremented by one each time and was easy to predict. Closed loop opt-in alone is not enough - it needs a unique unguessable token for each request. [at]thatsaspam If you are unable to identify the bad address, you could ask your list members to resubscribe (perhaps after your developer fixes the verification exploit). Another possibility is sending to a limited number of addresses every day while monitoring the blocklist to try to identify the spamtrap address.
  17. Snowbat

    [Resolved] SpamCop spamtraps

    You'd get a *LOT* more misdirected bounces if people like me weren't reporting them as the spam that they are. I get lots of traditional spam too - that doesn't mean I'd consider sending it. Which software does your mail server run? Qmail? Does your verification process use a unique unguessable token for each request? Which software do you use for your mailing lists?
  18. Snowbat

    Blocked IP address

    'pool' in the hostname frequently indicates a a pool of IP addresses that are dynamically assigned. It may well have been another Verizon customer that got this IP address blocked and Tim's machine picked up this IP address later. If this is what happened, solutions to prevent this happening again: - Get a static IP address from Verizon. They'll probably want to charge you extra but, given what happened, you could reasonably demand it for free or - Talk to your hosting provider. Do they know what they are doing? Whatever about incoming mail, I certainly wouldn't want to reject outgoing mail *FROM* paying customers based only on a SCBL listing. SpamCop specifically advises against using the SCBL for any kind of blocking, though it is not unusual for admins to use it for blocking incoming mail *TO* customers: http://www.spamcop.net/fom-serve/cache/291.html
  19. I concur. The format may look a little strange with HELO ID after the IP address but the parser had no problems with it. Chain test looks fine and no problem identifying the source IP in two examples I tried from http://groups.google.com/groups?scoring=d&...1+group:*abuse* Received: from [207.112.84.44] (helo=YOUR-97FD25D54E) by smtp-06.primus.ca with esmtpa (Exim 4.43) id 1FcvB9-0007Jl-Kd for ***^***.***; Sun, 07 May 2006 22:08:56 -0400 207.112.84.44 found host 207.112.84.44 (getting name) = dsl-207-112-84-44.tor.primus.ca. Possible spammer: 207.112.84.44 Possible relay: 216.254.136.21 216.254.136.21 not listed in relays.ordb.org. 216.254.136.21 has already been sent to relay testers Received line accepted
  20. From Wazoo's earlier post: Received: from bishop.idl.com.au ([127.0.0.1]) by localhost (bishop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29416-07 for <xxxxx>; Wed, 30 Aug 2006 17:39:33 +1000 (EST) Cannot accept line without valid 'by'. Skipping chain test - would fail. It looks like the parser rejected the 'by' entry because it was unable to resolve 'bishop' to 127.0.0.1. I guess 'bishop' comes from a hosts entry on your server or local DNS? Removing the entry from your hosts file or DNS should cause your server to stamp 'localhost' or 'localhost.localdomain' instead and the parser will accept that. Apart from having names and IP addresses that resolve, the chain test likes relays that are either in the same domain or have 'close' IP addresses.
  21. Snowbat

    I am at my wits end....keep getting listed

    Have you enabled message tracking and logging? http://www.msexchange.org/tutorials/Exchan...ng-Logging.html Exchange doesn't even do basic logging by default?
  22. Snowbat

    My address is being forged

    AKA thebroadcastemailcorporation.com/broadcastemailcorporation.org/broadcastemailcorporation.us This spammer appears to change the From and Return-Path on each spam to match the victim's domain name - ie. your domain name was used only in spam sent to you. The spam content and spamvertised domains have a Robert Soloway odor. http://en.wikipedia.org/wiki/Robert_Soloway
  23. Snowbat

    Blacklisted ... I know why

    How about running a local LDAP server and syncing it with your users' LDAP servers several times a day (and provide LDAP for those users who do not run their own)? You can then run your Postfix queries against your local LDAP server. That should stop almost all of the 'invalid recipient' rejects from those users. I don't know what to suggest regarding 'over-quota' rejects other than modify Postfix to to stop the bounce and write custom software to hold the rejected mails and put them back on the queue some time later, or drop your SMTP forwarding service and instead provide IMAP/POP3 accounts for your users. I'm seeing less than 500ms latency to a mail server in South Africa. The example you showed must have some pretty exotic routing, congested lines, and/or significant VPN encryption delays.
  24. Snowbat

    Whole IP address has been blocked

    Wrong for a number of reasons: If you send *anything* to a spamtrap, it is by definition spam. Spamtraps never send mail, request information, or subscribe to mailing lists. CR sent to an innocent third party (ie. the owner of the address didn't trigger it) *IS* spam. "Challenge/response spam filtering" http://www.spamcop.net/fom-serve/cache/329.html#CR "1.3 Challenge-Response systems make matters worse" http://pm-lib.sourceforge.net/README.html#4 As far as I am aware, the deputies do not investigate individual spamtrap hits unless an issue has been raised or as part of a random system audit. SCBL operation is described here: http://www.spamcop.net/fom-serve/cache/297.html
  25. Snowbat

    Whole IP address has been blocked

    If your "anti-spam software" is blindly pumping out CR to From addresses (that may be forged and include spamtrap addresses), don't be surprised if your own software has caused this listing. Your ISP will not be happy with you when they find out.
×