Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by eric

  1. Email forwarding is also not working. I'm set up to send my incoming email to Spamcop Email service for filtering, then they send the ham back to me at a secret email address. Nothing has come back from CES since about 9:30AM PDT today.
  2. [also posted on spamcop.mail newsgroup] No mail is being accepted for filtering at the Spamcop mx: [deleted][at]spamcop.net... Connecting to mx.spamcop.net. via esmtp... 220 mxin1.cesmail.net ESMTP >>> EHLO mail.[deleted].com 250-mxin1.cesmail.net 250-PIPELINING 250-8BITMIME 250 SIZE 0 >>> MAIL From:<[deleted]> SIZE=4578 250 ok >>> RCPT To:<[deleted]> >>> DATA 250 ok 354 go ahead >>> . 451 qq internal bug (#4.3.0) [deleted]... Connecting to mx2.spamcop.net. via esmtp... 220 mx70.cesmail.net ESMTP >>> EHLO mail.[deleted].com 250-mx70.cesmail.net 250-PIPELINING 250-8BITMIME 250 SIZE 0 >>> MAIL From:<[deleted]> SIZE=4578 250 ok >>> RCPT To:<[deleted]> >>> DATA 250 ok 354 go ahead >>> . 451 qq internal bug (#4.3.0) [deleted][at]spamcop.net... Deferred: 451 qq internal bug (#4.3.0) This seemed to start today at about 13:51 PST, and is still happening as of 15:29 PST. It appears to be an error at both cesmail MX hosts. As far as I can tell, this error is generated by qmail under some circumstances when it can't process an incoming SMTP transaction. No clue from the outside what the problem might be that started causing this just seconds after a successful SMTP message handoff.
  3. Here's another report. We are getting "451 qq internal bug (#4.3.0)" errors from mxin1.cesmail.net and possibly others. mx71.cesmail.net seems to accept incoming mail OK, haven't seen mail this morning processed by other MX servers.
  4. Definitely down, perhaps a local disk failure: telnet mx2.spamcop.net 25 Trying Connected to mx2.spamcop.net ( Escape character is '^]'. 421 unable to read controls (#4.3.0) Connection closed by foreign host. Can't receive new email, either, since our email is filtered by SpamCop mail. I would hope that loud alarms and pager pings go off when this kind of error occurs, but it's been at least 7.5 hours now.
  5. I have an email filtering account set up to filter all my email and forward it to a secret email address. Starting last night I'm seeing these errors while forwarding email to SC: Oct 12 08:40:17 mail sendmail[2124]: l9BHgrml019814: to=[me][at]spamcop.net, [user1][at]spamcop.net, delay=21:53:14, xdelay=00:00:00, mailer=esmtp, pri=2494409 , relay=mx2.spamcop.net., dsn=4.0.0, stat=Deferred: Connection reset by mx2.spam cop.net. Oct 12 08:40:17 mail sendmail[2124]: l9BHStOx019627: to=[me][at]spamcop.net, del ay=22:11:05, xdelay=00:00:00, mailer=esmtp, pri=2501800, relay=mx2.spamcop.net., dsn=4.0.0, stat=Deferred: Connection reset by mx2.spamcop.net. Oct 12 08:40:18 mail sendmail[2126]: l9CFeDOD002123: to=<quick.64TA0gYbpcQMPWYl[at] spam.spamcop.net>, ctladdr=<mail[at]mail.abcstuff.com> (8/12), delay=00:00:03, xdel ay=00:00:03, mailer=esmtp, pri=121815, relay=vmx2.spamcop.net. [], d sn=2.0.0, stat=Sent (ok: Message 1736896502 accepted) Oct 12 08:43:38 mail sendmail[2180]: l9CFhKBo002178: to=[user2][at]spamcop.net, delay= 00:00:05, xdelay=00:00:01, mailer=esmtp, pri=81112, relay=mx.spamcop.net. [64.88 .168.71], dsn=4.2.0, stat=Deferred: 450 Delivery delayed temporarily (#4.7.1) Oct 12 08:43:38 mail sendmail[2180]: l9CFhKBo002178: mx.spamcop.net.: SMTP DATA- 1 protocol error: 250 ok Roughly 50% of emails getting forwarded to SC for filtering are being rejected variously with "Connection reset", "Delivery delayed temporarily", or "protocol error" 4xx error status. The pattern seems to be that MX servers with names of the form "vmx*.spamcop.net" work fine, but servers "mx1.spamcop.net" and "mx2.spamcop.net" are not accepting incoming SMTP transactions from our mail server at Only mx.spamcop.net and mx2.spamcop.net are published in the DNS, I assume SC has some internal load balancing behind those two public names. If MX servers mx1 or mx2 come up in the rotation, the transaction fails. On an immediate manual rerun of the queue, the same message that had just been rejected is accepted by a different SC MX server. Maybe something needs a whack on the side?
  6. No, you miss the point. I have some number of email correspondents who, for better or worse, are stuck with ISPs that are listed on the SCBL from time to time. For example: AOL, Earthlink, etc. I am not about to whitelist the entire sending domain, but I would like to whitelist the addresses I expect to receive email from. A common starting point for that list is addreses to which I have sent email, plus addresses from which I have received email that I accepted. I would like to upload a list of those addresses in bulk. As time goes by, addresses on that list will become obsolete, and I would like to be able to delete them from the list. Paging through 35+ web pages is not my idea of the most efficient way to do this, especially if the one I am looking for ends up at the end of the list in sorted order. I guess I don't understand *your* premise! Are you claiming that you never receive email from anyone at a large ISP that gets itself listed, but that you want to whitelist so that the email gets through without delay? (or even worse, doesn't get through because it is buried in a pile of real spam, not false positives?)
  7. I know this has been mentioned from time to time in the past, but the SC email whitelist interface needs work, and now it's time. With the dramatic increase in spam of late, and the higher (in my personal experience) SCBL listing of certain ISPs causing desired mail to be blocked, the interface to the whitelist feature really needs to be augmented. The current interface simply doesn't scale. It would suit my needs if I could upload a text file of the same strings that are now used by the whitelist function, and have my uploaded list entirely replace the installed whitelist on my SC email account. With a matching download to text file capability, I can download the current whitelist, edit it to remove entries, widen/narrow the string match, and add lots of new names, then upload the new whitelist. With more ISPs getting listed due to p0wned boxen and whatever, the whitelist is even more important than ever to expedite desired email from senders stuck on those ISPs. When will this long-requested feature request be acknowledged, and maybe even scheduled?
  8. I wonder... since the "rule" says would it be sufficient to parse the spam both ways, with and without the so-called extraneous headers in question, and see if the results of the parse are in any way different? Cancel one, submit the other. If all reports and reporting addresses are the same for the two parses, then nothing was done to change what SpamCop found or did not find.
  9. Was working for me just fine at about 1700 PDT. Then on my next attempt to access at about 1830 PDT I got the "Connection refused" error from my browser. Still the case at 2200 PDT, five hours down and counting. Can't even telnet to port 80 on webmail.spamcop.net, connection refused. He's dead, Jim.
  10. I don't use Popgate, but in Internet tradition I'll take a stab in the dark I've seen this same behavior with our Eudora users if the local Eudora file gets "confused" i.e. loses its hash of MsgIDs which have been downloaded, and email messages get downloaded again (and again...). The downloaded duplicates are marked as "read", but they are downloaded as "new". New, but "already read". Since the POP client decides which of the available messages to download, I would tend to suspect a problem with Popgate losing its local database/hash of old messages, rather than a POP server problem.
  11. (Steering only slightly off-topic) This kind of thing is why I'm glad that the registrar I use for several domains (company as well as "vanity domains" for family and friends) has an automatic renew feature. If I keep credit card information on file with them, they'll automatically renew domains when they come up. That way I don't need to worry about forgetting, or being away on vacation for 2 critical weeks. Probably many registrars do this now, but it used to be rare. Even Network Solutions does it, I believe, although I certainly would not recommend them to anyone who is not already stuck with them. The registrar I do recommend, and use myself, is GoDaddy. <oblig>No connection, just a satisfied user.</oblig> A customer who was frustrated no end by NetSol's failure to respond to numerous technical issues over time, and thereby became an ex-customer of Network Solutions.
  12. [this comment probably should move over to the FAQ Under Construction forum] True enough, but the subject of uber-munging is not found by the Forum search function (until my original post in this topic/thread). Even the word "uber" only appeared twice, and not in the context of munging. In fact, if I click on the "Forum FAQ" link at the top of the page, and use my browser to search for the word "mung", it shows up only once in the whole FAQ page, in what turns out to be an answer to an ISP's question, not a typical SC user's question. A search for the word "mung" using the Forum search feature returns way too many results to be useful. The FAQ topic you suggested, about "mole" reporting, does not itself contain the word "mung". It is necessary to know to search the FAQ for one word or another, and if you don't know the magic word, you can't readily find the answer. That FAQ really seems to be intended to answer the question posed by someone who saw that term and doesn't know what it means. What I hear a need for many times is kind of the inverse, where the questioner knows some words which describe a concept, but don't know the correct term for it. I know just how hard this can be, since for my company web site search engine I have to try to come up with all the possible words someone might use to describe something they are looking for, when they don't know the correct "magic" word to use. Kind of like going into a hardware store to find a part when you don't know its proper name (and can't bring in a sample). Drives hardware store people crazy trying to figure out exactly which "doohickey" is the right one! It seems like there have been numerous posts here by someone asking a question, the answer given is "see the FAQ", but even a simple text search of the FAQ using words used in the question comes up empty. In this specific case, please consider these suggestions for the FAQ: - change the title of 'what is "mole" reporting' to something like 'what is "mole" reporting (see also "hiding your identity when reporting spam") - I gather that the original FAQ entries, of which the "mole" reporting is an example, are not easily edited because the individuals who have authorization are overloaded with other more important work. Otherwise, it would be good to add some "see also xx" cross-links. A good one here would be for the "mole reporting" FAQ to have a link to a new FAQ describing the spam Munging preferences option (which does not appear to be described in any FAQ, old or new, that I can find today). - add a new entry "hiding your identity when reporting spam" which describes the built-in munging options in the reporting User Preferences (namely "Obscure identifying information", "Leave spam copies intact", and "Become a "mole" - Don't even send reports (mostly pointless)". Good place to have cross-links to the above-mentioned 'what is "mole" reporting' FAQ, and to the proposed new "what is uber-munging?" entry - add a new entry "what is uber-munging" which might be derived from one of Mike Easter's descriptions. Unfortunately, I did not save any of them, and they seem to have expired off the NNTP server. Perhaps Mike can cons one up from his archive? Anyway, this is all meant as constructive suggestions to help people who come in here not knowing what they are looking for. For my company search engine, I try to ask as many "non-experts" as possible for the words they would use to describe something I'm holding in front of them; then I try to embed those words into my description. Sometimes it goes into an HTML comment, so it is searchable but doesn't clutter up the screen.
  13. The Preview Reports screen shows all the reports that will be sent, one after the other. I have my preferences set to mung, and the reports I just previewed do mung most of the appearances of my recipient address. Other clearly identifiable identifiers do not get munged -- my full name, my phone number, city name, whatever else the particular spam might have added. Could be to facilitate listwashing, could be to make the spam seem more "legitimate". If those un-munged identifiers are bothersome, see Mike Easter's discussions of "uber-munging" in the SpamCop newsgroups. I couldn't find any similar references here in the forum. Basically, it comes down to being impossible to completely remove any trace of which spam is being reported (and therefore which email address it was sent to). Even the number of spaces between words can be used to encode your identity for the spammer. Those garbage apparently-random letters might be an attempt to fool Bayesian filters, or they might encode an identifier. There's really no way for you to know for sure.
  14. OK, this second form (submitting spam to the 'quick.secretcode[at]..' email address) is the one that needs to be turned on by special request (and I hope lots of grovelling). IIRC, email sent to the 'quick.*' submission address results in a confirmation return email warning that quick-reporting is disabled due to misuse, and instead shunts the spam into the normal submit queue for later manual processing. I'll bet it's the first kind of quick reporting (VER or webmail) that is causing the trouble, and if I understand you correctly this also is supposed to be disabled by the "no quick reporting" flag, which in turn is supposed to be set automatically any time the user's mailhosts configuration is changed. Maybe there is a path through the code that doesn't do that, and is only traversed in some cases?
  15. Hmm. One of my users had exactly the opposite experience. With no request to enable quick reporting, her "Report as spam" button did quick report with no complaint, and as the mailhosts configuration was not complete it caused a bit of concern -- one report only, no no big problem, but nevertheless... I don't trust quickreporting enough to give it a test, just in case the button does in fact quick report. Side question: what actions cause the "no quick reporting" flag to be set? Would adding a mailhost? Would deleting all mailhosts? Would deleting all mailhosts and adding one or more new ones? Or is that flag set only on new SC accounts, and then not again?
  16. Sounds like you're using the webmail interface, and not VER, if the name on the button you clicked was literally "Report as spam". I think a possible confusing point, which seems to have ensnared you as it has others, is that the "Report as spam" button in the webmail interface does use quick reporting, and it doesn't clearly say so. The VER interface, which other posters may be talking about, has "Quick - report immediately and trash" as one of the selectable actions. However, from the webmail interface, it appears that quickreporting is the only easily accessed method for reporting spam. This would seem to be just a little dangerous. If the so-called "no quick reporting" flag indeed disables quickreporting, it should apply to the webmail interface as well as to the VER interface. Perhaps it does not?
  17. Well, since several key SC personages have stated that they intend to frequent the forums, and not the newsgroups, it seems clear that "the newsgroups are deprecated to the extent they are." I'm sorry you were not aware of it. BTW, your definitions are deficient.
  18. [must ... sleep ... before ... posting ...]
  19. Yes, the problem of scraping email addresses and other information is a problem, but Google and other forthright search engines do respect the robots.txt file. Even though spammers don't, it seems to me (ISTM) that it would be worthwhile for the SC forum to discourage search engine glomming of the forum since there is a reasonable internal search capability. Or perhaps prohibit Googlebot via the robots.txt, and feed a suitable input to Google via their subscriber feed, perhaps masking email addresses and other personal identifying information. The scrapers who find anything with an at-sign in it (like neko[at]spamcop.net which is an eminently scrapable, never validly used, even spam-trappy address) will send spam to those addresses. Reputable spiders will never get to those strings because they obeyed the robots.txt prohibition which kept them from fetching that file in the first place. I'm very bummed that the newsgroups are deprecated to the extent they are. I hate being forced to be onlne to read any single posting, rather than fetching a newsfeed and reading all articles at my leisure. But I've been a Usenet denizen since '82, as admin of UUCP host 'wombat', so what could I possibly know...
  20. Unfortunately, this is not totally correct. What it means is that some infected PC has you in an address book, or has your email address in any of the myriad text files that a virus might scan and "phone home". This has resulted in your email address being added into a virus-fed list. Some [possibly other] infected PC sent the virus to your email address because it appeared on a list of live email addresses known to the virus. (or has been published in a Usenet news article, or any kind of Internet message, even IM/SMS to an infected PC/phone.) Your email address got added to the virus's list somehow. Bummer. This list is especially "target-rich" because it includes email addresses culled from actual live email inboxes, as well as email addresses [valid or not] scraped from address books, bookmarks, and plain text files on the victim's PC, all of which are very likely to be live addresses. Moby bummer. The virus-infected PC is not necessarily the source of the spam; indeed, it is very unlikely to be the actual source of the spam. The virus has transmitted your email address (and many others) back to the Mother Ship, so that spam can be sent to the harvested addresses. Molto moby bummer!
  21. I have to say that sometimes I have been confused by comments that showed up in an unexpected placement. It was never clear whether this was due to my viewing preferences or the poster's choices. Please be sure to publish the definitive results of the study!
  22. I hate it when I'm the last to notice something... Google has been spidering and archiving this forum, and that's a very different policy than the [unfortunately deprecated] newsgroups officially have/had. No doubt other search engine spiders have been feeding as well. Is there an official reason why there is not a robots.txt prohibition for search engines on the forum pages? If not, then posters may want to be aware that their words not only will be preserved for posterity, but that they will be searchable and "Googleable". Another reminder that you might not want to post here, or in a newsgroup, anything that you would not want printed out and posted on a wall somewhere. [Timely holiday tie-in:] Or sent to your mother! This is a civilized society. Be civil at all times...
  23. Those headers you have posted appear to have been altered, perhaps by you in order to mung identifiers. If not, then there are some real problems at your email server! I'll pretend that all the necessary information is still there... The Date: header shows the email sending time as 03:29:17 UTC (06:29:17 +0300), which corresponds with the 12:29:17 +0900 you are seeing in the mailbox list. Usually the Date: header is set by the sender's PC; if it is not, it should be set by the first SMTP server to handle the message. The Date: header is completely under the control of the sender, and is ordinarily set to the local system time on the sender's originating (sending) email server. I say "ordinarily", because there are lots of ways that this header can be forged to show a different time, and spammers sometimes take advantage of them. Regular email from ordinary senders should use their local system time, so if this line is wrong, it usually means the time is set wrong on that computer. You say that your mailbox listing shows the time on this message as 12:29:17, but that it should be 11:36. The difference between :29 and :36 could just be the difference between two clocks (in this day and age, with Internet time servers available, there is no good reason for a 7 minute difference any more, but not everyone uses a time server to make sure their system clock is correct). So the guess is that the sender's PC clock is set 1 hour ahead of what it should be, perhaps because the timezone is set wrong. This is where the timestamps on the various Received: headers are useful. They can be expected to be off by up to several minutes in either direction, compared to other timestamps, but certainly should be in agreement as to which hour of the day it is (after taking timezones into account). It's like asking people on the street what time it is. Each will look at his watch, and each answer might be just a little different, but they all should be within a few minutes of each other. If one is off by an hour, you might be tempted to ask if that person just arrived on an airplane and forgot to set their watch to the local time! I'll ignore the X-OriginalArrivalTime: header, because I have no idea where that header was inserted. There's no way of knowing, because it is a non-standard user-defined header. The first (bottom-most) several Received: headers are clearly bogus forgeries. The hostnames are illegal, and they all have the same IP address. Interesting that the timestamps are slightly different, perhaps an attempt to make the forgery appear more legitimate? They are internally consistent as far as timezone and hour-of-day. But since they are not to be trusted, this is just an interesting point to note. Although you did not say so, this appears to be a forged email, probably spam. Looking top-down, the Received: headers go from trusted (your own email server) to increasingly untrusted, since any server along the way could be compromised. Once you hit an untrusted or compromised server, no Received: headers from that point can be trusted. The SpamCop headers can be trusted so look at those timestamps. 02:36:11 -0000, 22:36:01 -0400, 02:36:00 -0000, 02:36:00 -0000, 22:36:00 -0400 all are consistent. And all are an hour behind the time shown on the Date: header. Not much point in going further, it looks like the spammer doesn't know what time it is!
  • Create New...