Jump to content

Vanguard

Members
  • Content Count

    40
  • Joined

  • Last visited

Everything posted by Vanguard

  1. I went through the Mailhosts procedure mentioned at mhconf.<code removed>[at]cmds.spamcop.net by clicking on the bottom link. I got the confirmation e-mails (2 of them because 2 gateways were listed for my Comcast provider). One option was to forward that e-mail as an attachment to a specific SpamCop address. Outlook has the option to forward as an attachment and that is how I configure it to behave. Forwarding inline loses all the headers for the original e-mail but they are there when sent as an attachment. When forwarding e-mails, I want the recipient to get the same exact message that I got, including the headers. A very short time later, I got 2 more e-mails for each test (for a total of 4 e-mails for the 2 confirmations which I forwarded as attachments). Basically, for each "SpamCop account configuration email" message that I forwarded back as an attachment, I got 2 replies: "SpamCop account configuration: error" "SpamCop account configuration: success" Because these replies were sent out almost at the same time, they might appear in the order shown above or in reverse order. So, at this point, and because there is no way to check on the status of my account regarding this mailhost parsing setup, I don't know if the setup was successful or failed. When attaching an e-mail as an attachment when forwarding it, it gets attached as a .msg file. Maybe SpamCop doesn't know how to parse and interpret .msg files. If so, I could use the web form where I paste the headers and body. However, at this point, I don't know if I should do that since I don't if it trying requalify a success would result in a problem. How do I check if the mailhost check was a success (since I got both a success and failure message)? Should I try using the web page link in the first e-mail ("SpamCop account configuration email") to try again?
  2. I'm starting to suspect we got ourselves a troll here.
  3. I use SpamPal. It has a Bayesian plug-in so it will "learn" like you mention. It helps if you have a set of good e-mails and a set of spam mails to feed it as good and bad to preload your Bayes database; otherwise, you'll spend some time with it in learn mode weighting keywords in the e-mails you receive after installing and enabling it. Unlike other Bayesian filters which work alone and so they can only based their judgement regarding spamminess on just the content of the e-mails, the SpamPal Bayesian plug-in can learn from SpamPal's blacklists and from the other plug-ins. This helps the Bayesian filter keep in sync as to what is spam because it has been identified as such using other methods than just a weighted database of words. It also has a Reclassify window that you can use to change the status of an e-mail from spam to good (false positive) or from good to spam (false negative) in case the spam got missed by everything else, including the Bayesian filter, or you consider it a false positive. Don't expect Bayesian filters to be some omnipotent spam catching mechanism. The technique is fallible. Some spam actually tries to poison the Bayesian filter (they look to be targeting the one in Outlook 2003 because the one in SpamPal has a configurable word expiry to eliminate the "noise" floor of its database). SpamPal also uses DNSBLs. Blacklists are its primary means of detecting spam. However, it is up to YOU to investigate how each blacklist works and what they list. SPEWS, for example, is not interested in providing a list of actual spammers. They are interested in penalizing ISPs by cutting a wide swath of their IP addresses; i.e., they rate the trustworthiness or spamminess of an ISP or e-mail provider rather than identify the spammers there. They rely on the victims at the spam-lazy or spam-friendly ISP that are getting notified that their e-mails are getting block by their recipient to complain to their ISP. SPEWS wants to coerce the victims at the penalized domain to complain to that domain. Other blacklists are more focused at actually identifying the spammers, a task that is difficult because they keep moving. SPEWS and SORBS don't update their lists very frequently. When my IP lease expired and I got a new IP address from my ISP's IP pool, it was in SORBS blacklist but the last update on whomever they thought was spamming from it was over 3 months old. SORBS was responsive and manually updated their records the next day, but obviously the 3-month old record (and other remarks about them) show that they are slow to update, so to a degree they are like SPEWS which is quick to add, cut a wide swath, and slow to update (but their intent is not to be current to identify spammers but to rate a domain regarding trust or spamminess). Investigate the blacklists you use. Another example is blacklisting by country. SpamPal lets me do that. I can blacklist e-mails that originate from certain countries. That doesn't mean all e-mails from those countries are spam. However, I do not correspond with any entity in those countries so any e-mails originating from there were unsolicited. SpamPal does have a Logfile plug-in that retains a text-only version of all spam-tagged e-mails. This lets you recover from a false positive. That way I can have my e-mail monitor (Magic Mail Monitor) where I can define rules that delete spam-tagged e-mails off my mail server without every having to download them (make sure to test only on headers) but still have enough info in the logs to identify the sender should a false positive occur. Unfortunately the Logfile plug-in does not automatically expire the logfiles so I wrote a batch file that kills logfiles over a specified number of days old and then add it to Task Scheduler (and I gave a copy of the batch file to the plug-in author who has a link to download it from his site). Another means of avoiding spam is to block any e-mails that originate from a mail server that has a dynamically assigned IP address. Dial-up and cable/DSL users have dynamic IP addresses. Their zombied hosts running a mailer trojan will spew out its spam but SpamPal's MXblock plug-in will see it came from a dynamic IP address and tag it as spam. I did edit the MXblock plug-in's config.dat file to specify the SpamHaus DUL (dynamic IP list) rather than use the outdated MXEasy list. It has worked many times to identify spam that came from zombied users. SpamPal has a RegEx plug-in if you want to define regular expressions which go far beyond what you can define using the rules in your e-mail client. SpamPal and its other plug-ins have been so successful at identifying spam that I have never need to use the RegEx plug-in. The HTMLmodify plug-in not only makes HTML-formatted e-mails more safe (although your first defense should be using the Restricted Sites security zone set to its High level) but also detects spammy mails based on their HTML characteristics, like too many bogus HTML tages (spammers will hide their message inside an illegal tag because it won't get rendered and will show as e-mail but many filters will strip out any strings that look like HTML tags), URL obfuscation (which it will de-obfuscate), The URLbody plug-in will identify spam based on a URL link within the body of the message that goes to a known (i.e., blacklisted) spam site. However, while it sounds nice, it can be somewhat aggressive. Like the Bayesian plug-in, the URLbody plug-in must download the entire message so it can look inside the body. If you want to eliminate spam then YOU will have to take action to do so. Stop relying on reporting the spam to the ISPs in some altruistic hope that those ISPs will be oh so ever responsive to those reports. The reports do help but my guess is that put all of maybe 10% of a dent in the volume of spam. You'll need to be aggressive and use something more than complaints to avoid getting spam. With SpamPal, you get an entire suite of different methods to detect spam, and SpamPal is free. If you are looking only for one method to identify spam, say, Bayesian, then you could try SpamBayes. It runs as an Outlook plug-in but, I believe, it will also run as a proxy, like SpamPal, so any POP3/SMTP compliant e-mail client can use it. SpamPal has its own forums for support. Buy a commercial product if you have the need to call someone for support. But do something more than just report the spam. Whining about spam and bitching to ISPs and e-mail providers is not going to eliminate the spam in your Inbox. It will eliminate some. I report spam through SpamCop not only to bitch to the e-mail providers but also to update SpamCop's blacklist which gets used in SpamPal. Whether the e-mail providers uses the SpamCop report or not, SpamCop's blacklist gets updated and I get the benefit of not getting more spam from that source (if there are enough reports about the spam source). Whining only works to a small degree, so choose to control what gets delivered in the first place.
  4. Reporting the spams to the ISPs (actually the e-mail providers) only gives them the opportunity, if they have the desire, to clean up their service to keep them from eventually getting blacklisted. Whether or not they cleanup their e-mail service doesn't prevent you from using the DNSBLs (DNS blacklists) to block spam, so you and others reporting spam will update the blacklists of known spam sources and using those blacklists will eliminate getting more spam from those identified spam sources. You can report all you want but don't rely on e-mail providers being nice. If you don't report bad food or service to the restaurant manager, they won't know there is a problem or its severity. Even when you do report the problem, it's still their choice whether or not they do anything about it. If you use SpamCop then you should also be implementing DNSBLs to avoid getting the spam. If you don't want to pay SpamCop for their spam-free e-mail service, you could use SpamPal or Mailwasher to use the DNSBLs to avoid the spam. What's the point of reporting spam when you already know the e-mail providers are likely to ignore the problem or won't address the problem immediately? To reflect their spamminess in a blacklist that you actually USE. Many blacklists don't even bother notifying the e-mail providers of the spam but just update their blacklist with every spam report or with their automated spam detection methods. Some e-mail providers do use the spam reports whether they come from SpamCop or directly from you. Some don't. Are you going to rely on the nicesness of e-mail providers to eliminate spam from your mailbox? Get real. Will a burglar stop taking your stuff while you simply nag at them to stop it? You lock your doors and maybe even bar your windows, and that what is USING the blacklist(s) provides to you.
  5. Turns out the e-mail address in the submitted message was invalid but I had changed it, or so I thought. I had decided not to bother specifying an e-mail address for newsgroup posts. I wanted to keep all replies in the newsgroup and prevent anyone from disconnecting it via e-mail (i.e., share with others or don't bother to post). I would no longer bother to maintain an e-mail account for newsgroup replies since I don't want and will no longer accept e-mails for newsgroup discussions. An e-mail account is not mandatory to actually use NNTP. The e-mail address will be fake or munged. Since I wasn't going to maintain an e-mail account that might allow for disconnecting the discussion via e-mail, there would be not point in munging an e-mail address. Instead the e-mail address would be fake. What is the difference between a fake e-mail address (to which you cannot send e-mail) and no e-mail address (so, again, you cannot send e-mail)? One difference is that the potential respondent might send off the e-mail to the fake e-mail address, if permitted, and not realize why there was no response. However, trying to send to an invalid e-mail address would immediately alert the user that was impossible, so it would prod the user to put their reply back in the thread in the newsgroup. Another difference is RFC compliance, but NNTP doesn't actually go through an e-mail account so an e-mail account was and is never actually required, and we already know that many of the RFCs are outdated and don't reflect current real-world conditions. As a result, and after deleting the e-mail account previously assigned for any newsgroup replies sent via e-mail (which I didn't want and rarely received), I configured my news accounts to *not* specify an e-mail address. I've done that before with other NNTP servers, like my old ATT/Comcast NNTP server (now defunct) and with Giganews and Microsoft that I'm use now. It was several days later that I then attempted to post to the SpamCop NNTP when it complained about the From header. When trying to figure out what it got that it was complaining about, and because I was used to other NNTP servers accepting my values, I just didn't hit on what to look at last night (I was exhausted and got stuck focusing on why *that* message generated the "441 invalid From syntax" error). After some sleep and some coffee, I did what I should've done last night: look in raw mode to see what it was that I was sending since the troubleshooting logfile didn't tell me and the error message sent back from the SpamCop NNTP server didn't mention what value it got that it was complaining about. The problem was ... (drumroll) ... the copy of the message in the Outbox is static. That is, once composed and moved into the Outbox, any changes to your accounts are not reflected in your pending outbound messages. I had sent the message so it was in my Outbox, the send got rejected, and it sat in my Outbox. I changed my settings according to SpamCop's complaint but that didn't resolve the problem because messages in the Outbox don't get updated. Messages in your Drafts folder will get updated if you change your account settings before sending those messages. However, messages in the Outbox are static: their headers remain fixed to whatever were the settings in your account at the time you composed the message (rather than add or update those headers to match your account settings during the SMTP or NNTP session). So, yeah, I was changing to a validly syntaxed e-mail address in my account settings but that did nothing to update the message sitting in my Outbox. Argh! Time to add something stronger to my coffee. A test this morning clued me in. I sent a new post and it worked because there was a validly syntaxed From header used in the message. Then it dawned at me to use raw mode to look inside the message rather than rely on looking at what the UI presented to me. Seeing "Vanguard" in the From header shown in the UI version of the message doesn't help because that is what I always see (it doesn't show the e-mail address, only the name that I use to identify myself). Silly me for thinking the application would use whatever values were currently configured for an account when I send a message. The way to get around the problem is to reopen the message in the Outbox and then send it. Opening it makes it sync up with the new settings because there is an implicit Save operation which causes an update to the message to reflect the current account settings; i.e., an implicit Save after opening and resending (or a manual Save followed by a resend) gets the current account settings used in that message's headers. Server: Your From header isn't a valid e-mail address. Me: Okay, so I'll change it just for special little you. Here it is again. Server: Your From header isn't a valid e-mail address. Me: Yes, it is. Server: No, it isn't. Me: Okay, then try this one which is valid. Server: Nope, won't take that one, either. Me: What?! Well, how about this one? Others say they can use it. Server: Nope, don't care, yours is invalid. Me: But it works for others. Server: Don't care. Not valid. Me: What the fu..?! Server: I don't do requests, and you're not my type, anyway. Me: (Get some sleep.) Me: (Next morning, send a *new* message.) Server: That one has a valid From header. Me: But it's the same one for the other message. Server: Nope, but I'm still not going to tell you what *is* the value that I don't like. Me: But the From header does have a ... hmm, wait a minute ... what if ... (looks in raw mode) Me: Hey, that still has the original invalid e-mail address that I changed. What gives? Me: (Opens old message and resends it okay.) Me: Huh, now that From header that was invalid before is okay now? Server: Well, what you sent now is okay. Me: (Do a couple more tests.) Me: Okay, looks like the old message still had the old bad value. It updated when I *opened* it again instead of just resending it. Server: See, I was right. User error. Me: Oh, shut up! You're the only one that bitched in the first place. No one else complains. Now you know why I felt like I was on the wrong end of a comedy skit.
  6. I've been using the news.spamcop.net NNTP server for awhile. I didn't need to specify an e-mail address, especially since I never take any discussions offline to disconnect them from other group participants. There's no point to specify an e-mail address or even require one since everyone knows that it will be bogus to avoid the spambots from harvesting them. Even SpamCop's own help pages regarding the forum says to use a bogus e-mail address. When I attempt to submit a post, the news server now looks for a validly syntaxed e-mail address in the From header. Okay, so why won't it accept one? Currently I am using "reply2group[at]email.invalid" but only for those NNTP servers that demand that there be something in the From header. That *is* a validly syntaxed e-mail address. If SpamCop's news server won't accept .invalid as a top-level domain than it is screwed up. One of the easiest ways to munge an e-mail address is to use .invalid or example.com. So why the recent change in the server's handling of the From header and why won't it take validly syntaxed e-mail addresses? I get the following error messsage from OE: Outlook Express could not post your message. Subject '<subjectheader>', Account: 'Newsgroups - Spamcop', Server: 'news.spamcop.net', Protocol: NNTP, Server Response: '441 From: address not in Internet syntax', Port: 119, Secure(SSL): No, Server Error: 441, Error Number: 0x800CCCA9 I enabled the OE troubleshooting log (show below) but it didn't provide any more details regarding why the Spamcop NNTP server is bitching about the From header's value. Microsoft Internet Messaging API 6.00.2900.2527 (xpsp_sp2_gdr.040919-1056) NNTP Log started at 05/25/2005 20:17:30 NNTP: 20:17:30 [db] Connecting to 'news.spamcop.net' on port 119. NNTP: 20:17:30 [rx] 200 news.spamcop.net InterNetNews NNRP server INN 2.3.2 ready (posting ok). NNTP: 20:17:30 [tx] MODE READER NNTP: 20:17:30 [rx] 200 news.spamcop.net InterNetNews NNRP server INN 2.3.2 ready (posting ok). NNTP: 20:17:30 [tx] POST NNTP: 20:17:30 [rx] 340 Ok, recommended ID <d7383a$u1m$1[at]news.spamcop.net> NNTP: 20:17:30 [tx] . NNTP: 20:17:31 [rx] 441 From: address not in Internet syntax NNTP: 20:17:31 [db] Connection to 'news.spamcop.net' closed. Something changed (and the change was wrong). I've tried several e-mail addresses (none of which are my own but all of which use valid e-mail syntax) and I get the same error. I don't have the problem with any of the other NNTP servers that I use (Giganews' and Microsoft's), and this just was noticed today. Well, the last time that I tried to post was back on the 20th so it could've happened anytime in the last 5 days for this particular NNTP server. I can read but I just cannot post, and the error is bogus since the syntax is valid for the e-mail address in the From header.
  7. Okay, now it gets strange. When trying to submit my prior reply post, SpamCop's NNTP server would spew back its 441 error saying it didn't like my From header. So I tried replying to another post and that one got accepted. Huh? It didn't like my From header before (or now) for replying to that other message, but my From header is okay when replying to a different message?
  8. I just tried "vanguard[at]nixnntp.com" (after first checking that nixnntp.com was not a registered domain so it couldn't be inuse somewhere) and it still didn't like that one. I don't want to using a registered domain because I'm not interested in energizing spam at some innocent. The line from the troubleshooting log that says: NNTP: 20:17:31 [rx] 441 From: address not in Internet syntax The "[rx]" means that status line was *received* from the news.spamcop.net server. So it was the NNTP server that rejected the From header's value. Right now it is rejecting whatever I put in that header. Since the value of the From header can be seen whenever I post to other NNTP servers, I know that what I am specifying in OE for the From header (for the Name and E-mail address fields in the account definition) is getting sent to the NNTP server. By seeing my posts sent to the other NNTP servers, I can see what the value was in the From header that it got from my NNTP client. Since Spamcop's message doesn't specify what it got for the From header that it is complaining about, I cannot guarantee what value it received. However, since it works for all the other NNTP servers then the finger pointing is directed at the SpamCop server. I don't know why you could get it to work, especially since you did not use the "recommended" fake e-mail address (I was thinking that maybe someone screwed up and was forcing everyone to use the same fake one, but not even a legit one got accepted). However, you did post to a different group than I am trying to use. It would seem weird and silly that the NNTP server would have one set of rules regarding the From header depending into which group the message got posted. -- UPDATE -- Oops. See that you simply *found* a post from earlier today that was from someone using nobody[at]nowhere.invalid. My last post was back on the 20th so all I could claim is that something changed since then and when I tried posting about an hour ago (and ever since then). So maybe the "change" occurred sometime after 5PM today (which was for the post that you noted).
  9. That should be considered ONLY a suggestion. It would be utterly stupid for every poster to use the same e-mail address in the From header. Why? Well, say you have a puerile malcontent that wants to troll or flame in the groups provided by the SpamCop NNTP poster. How can you killfile (plonk) that poster if he/she uses the same e-mail as everyone else. What a wonderful concept. Have everyone use the same e-mail address to render completely unusable the ability to killfile any undersirable posters, or killfile the one troll and end up killfiling everyone (so why bother visiting the group if you're not going to see anyone's posts?). Why do posters [hopefully] use different monikers to identify themself when they post? So you get used to who is posting and can differentiate who is submitting the post and who is replying to it. The e-mail address should also be unique (but munged) *if* it is supplied at all. If you have absolutely no desire to disconnect the conversation by taking if offline via e-mail then why even bother providing a munged e-mail address? Yeah, some NNTP servers still require something in the From header but then you end up just putting in a completely bogus e-mail address or one that directs to a null service (so obviously there was no point in providing an e-mail address in the first place). If you do want to provide an e-mail address as an additional part of your identity then you should be able to munge your e-mail address, and using the .invalid TLD is perfectly legitimate not only for munging but as the e-mail value in the From header. Telling every poster to use the same e-mail address is stupid. It is more likely that posters (that use e-mail values) will have different e-mail addresses than they for having different monikers. In fact, the ploy of a malcontent is to impersonate someone else by using their moniker AND their e-mail address, so when someone plonks them then they also plonk the impersonated user. Also, the fact remains that something has changed. If you look at my prior posts to the spamcop group on the news.spamcop.net server, I used "vanguard[at]domain.invalid". Obviously that was accepted because my posts are there. Something has recently changed that won't accept that or any other validly syntaxed e-mail address. I even tried vanguard[at]example.com and it won't accept that one, either! And to add, using a valid domain that then sinks e-mails sent to that hostname still wastes resources at the recieving mail server. I munge the domain to deliberately specify a domain that doesn't exist. That way, the sending mail server can't even connect to a receiving mail server. It dies immediately when trying to send, not sometime later after sending and the receiving mail server has to waste CPU cycles and resources to auto-delete or reject it on delivery.
  10. I got a reply from Ellen (via e-mail) and from SpamCop Admin (also via e-mail). The problem was from several contributing factors: - The cookie login takes me into whichever account was last used. I typically login under account #1 and the cookie relogs me back into that account when I click on the link in the "accept" SpamPal reply after sending the spam report to SpamCop. - The spam reported from Outlook Express used the submit.<id>[at]spamcop.net e-mail address for my account #2. The Past Reports list records spam based to which SpamCop the report got sent (by the submit.<id>[at]spamcop.net e-mail address), not according to account you log under to complete the submission. So I sent to my submit e-mail address for account #2 but was logging on under account #1 to complete the submission. If I had logged out and back in under account #2 then I would've seen my recent reports submitted to account #2. - To further exascerbate the problem, I had an old and defunct SpamCop account #1 registered for my personal e-mail address. However, the account under which I was logging under and the one for the submit.<id>[at]spamcop.net e-mail address to which I was sending spam report was for a newer account. At some point, I must've abandoned my old account and had to create a new one. The help tells users to create a new SpamCop account rather than try to get the admins to reset the password, so maybe that is what happened. Both the old and new accounts had the same e-mail address listed but had different submit.<id>[at]spamcop.net e-mail addresses for reporting spam. Luckily I was using the submit e-mail address for my newest SpamCop account with that same registered e-mail address. I thought I would need a separate SpamCop account for each e-mail address but that is not correct. My mistake was thinking the "accept" replies from SpamCop after sending them a spam report would get sent to the e-mail address specified in my Preferences setting. Nope, those "accept" e-mails get sent back to whatever e-mail address sent the spam report in the first place. I was thinking that I would need multiple SpamCop accounts to ensure those "accept" messages got sent back to the proper e-mail account that was managed by the same e-mail client that handles the account from which the spam got reported. I use Outlook for one group of my e-mail accounts (personal and work) and I use Outlook Express for another group of my e-mail accounts (forums and newsgroups). Because the "accept" reply goes back to whatever e-mail address was used to send that report, it will show up in the appropriate e-mail client. I also wasn't used to performing tasks which should be going through account without actually being logged in under that account. That is, when you send a spam report to SpamCop to your account #2, you can be logged in under your account #1, or anyone's account, or not even logged in to complete the submission. I wasn't used to this lack of security. Apparently this has not yet been a security issue. As an aside to this discussion, I remember reading in the registration e-mail or in the help that I should keep private my submit.<id>[at]spamcop.net e-mail address to which I send spam reports. Presumably anyone could send messages to that e-mail address and potentially cause problems or deliberate abuse. Although I can use one SpamCop account to send spam reports from multiple e-mail accounts of mine, so can anyone else. I would think for security that users would be required to list from e-mail addresses their account will accept spam reports. When the user adds an e-mail address to their Preferences (which requires logging in), a confirmation e-mail gets sent back to complete the addition of that e-mail address. That way, anyone getting your submit.<id>[at]spamcop.net e-mail address cannot abuse or usurp it because the "accept" replies from SpamCop would still be getting sent back to the real user's authenticated account(s). To summarize: Issue with Past Reports has been resolved and found to be the typical source of problems: user error (more colorful expression also apply).
  11. When looking under the Past Reports tab, the last report shown as submitted is dated back on May 12. Yet I've submitted reports once, or more, per day since then. Why isn't this list getting updated? I went there because I wanted to check on an IP address for a just submitted report but that list is too old.
  12. Yeah, I wasn't sure if posting here (on *how* to report) was an appropriate place to report problems with the service. So I'll go hunting for an "upstream" contact to report the issue. Thanks anyway.
  13. When I send the attached spam via e-mail, I'm "requesting to submit" the report (as obviously I cannot force SpamCop to do anything regarding my e-mail sent to them). When I get the reply e-mail with the link, click on it, and okay that report, I'm "completing the submit". "Sent" could simply be that I sent them the attached spam in an e-mail which was the first step for "requesting to submit", so "sent" isn't a complete and accurate term, either. I really didn't want to bother saying that I "requested a submit and then completed the submission", and instead used "submit" to refer to the entire process. I have sent spam as attachments to SpamCop. SpamCop then sent me a reply e-mail with the link to their parser web form. I then completed that submission so the report would get filed and SpamCop's version of the spam reports get sent to the selected recipients. So what do YOU call that entire process without having to use an long descriptive paragraph? And why would "sent" be any better than "submit"? Sent just means I sent the spam to SpamCop. "Submit" sounds like something further in the process than just "sent". "Send" doesn't differentiate between me first sending the spam to SpamCop or when I click the "Send" button in their web form. If you look at the web form after clicking on the reply e-mail from SpamCop (with a Subject of "SpamCop has accepted 1 email for processing") which shows the parsing, look at the HTML on that page. You will see the button titled "Send spam Report(s) Now" is: <input type="submit" value="Send spam Report(s) Now"> So saying that I submitted the spam report is accurate since that is what I did by using that control in that web form. The text for the input control can be anything, even "File this report and send copies of it to the selected recipients" but that doesn't change that the action taken was a submit. So now that we've wasted time arguing over terminology, why isn't my Past Reports list getting updated for spam reports from the last week that have been submitted, sent, filed, recorded, or whatever you want to call it? Rather than this forum, is there a more appropriate contact that I should notify regarding this problem?
  14. Yep. I didn't remember the report ID and so I just clicked on the link to view recent reports. The most "recent" report listed is over 8 days ago.
  15. See http://www.spamcop.net/sc?id=z763127086z16...4f27973158fac1z for my spam report. Notice it says no links were found in the body of the e-mail. Yet there is a link: <A href="http://ntoslal.net&sxwgzihurfngdush5utq4x.bramiadcjlj.com/"> Does SpamCop's parser have a problem of knowing to terminate the parsing at the first illegal character used in the domain portion of the URL? Isn't the URL pointing to ntoslal.net (which is what the deobfuscators say it is), or is it bramiadcjlj.com? I know that I can specify either http://support.microsoft.com/?id=300698 as a URL to a Microsoft KB article but http://support.microsoft.com?id=300698 also works, so I figure the domain URL parsing stops at the first character that isn't allowed in a domain, and that would the ampersand ("&") character. Even if the domain is no longer registered, shouldn't the parser note the domain from the URL (so you are reminded that there is a URL to site within the body without having to view the entire message) and also note that there was no lookup on it at that time? I would've thought the first part of the domain portion of the URL would've been truncated at the "&" character and the first part used. But according to another SpamCop parse shown at http://www.spamcop.net/sc?id=z763048974zd6...1ea2ea24dbe1f9z, it trashes the first part before the "&" and uses the second half. The deobfuscators that I've used return the first part before the ampersand. In fact, a real easy deobfuscator is to simply use the ping.exe program. When I run: ping kwmsbgk.net&trjqauq2hnd6l2ipv2jgc5.bokarknjkjl.com it is trying to ping kwmsbgk.net. It seems SpamCop's parser is using the wrong portion of the obfuscated URL. As a result, SpamCop will be sending it spam reports to wrong recipients, something that I've heard accused of SpamCop. For this particular spam report, I decided to deselect the Chinese contacts because they were based on the domain extracted from the URL but SpamCop used the wrong portion of that URL.
  16. Vanguard

    Parser cannot find URL links in body

    I didn't see Ellen's or your posts in the newsgroup because I had plonked a couple of other posters that used "nobody[at]" as their e-mail address (with the same domains as you and Ellen). It was because I saw Mike Easter quote your post but I couldn't see your post that I figured my rules were deleting some posts that I did want to see. So I reset the group to re-retrieve the message headers and, voila, there were Ellen's and your posts. I tried ping and it tried pinging on the domain portion *before* the ampersand. I used dnsstuff.com's deobfuscator and it parsed up to the ampersand to return the first part of the URL before the ampersand. Then I tried SamSpade for Windows with the full URL and it came back with a location of the full domain portion with just the ampersand stripped out. So I wasn't sure what to believe at that point as to what was the correct domain to be reported for the spamvertiser link. I wanted to make sure not to irritate someone that wasn't involved in delivering the spam. Guess I need to find better deobfuscator tools that take in account deliberately bad syntax. Several of them that I tried would just bitch back to me that the syntax was invalid. Well, yeah, I knew that but I wanted to find out what would get used anyway, if it got used at all. Thanks for the help all, especially Ellen.
  17. When submitting a spam report, some of the contacts may be listed as not accepting munged e-mail addresses for the spam reporter. Okay, but does that mean just one copy of the e-mail goes out with my unmunged e-mail address so all recipients of the spam report can see it? Or does a separate copy go out munged to some contacts and another separate copy go out with my unmunged e-mail address to only those contacts that won't accept munged e-mail addresses? If I chose to send my unmunged e-mail address in a spam report to, say, a known ISP so they get it, that does NOT mean that I want every other recipient to get my unmunged e-mail address. It is possible that one of the contacts is the spammer themself and I really don't want to energize more spam at my mailbox by revealing my unmunged e-mail address to them.
  18. I went back to the original spam e-mail in my Deleted Items folder in Outlook. Its header had: Received: from 20.97.119-80.rev.gaoland.net ([80.119.97.20]) by sccrmxc24.comcast.net (sccrmxc24) with SMTP id &lt;20050511154101s24007dec7e&gt;; Wed, 11 May 2005 15:41:14 +0000 X-Originating-IP: [80.119.97.20] Received: from BGNYUNC (poesb.offenburger.com[151.191.254.93]) by lxzxpesv.offenburger.com (Postfix) with SMTP id 3F4M1T2033 for &lt;crfannon[at]comcast.net&gt;; Wed, 11 May 2005 10:44:05 -0600 (envelope-from QCPDWB[at]offenburger.com) From: "Trevor Crouch" &lt;Nwsasfs[at]offenburger.com&gt; To: "Crfannon" &lt;crfannon[at]comcast.net&gt; As the SpamCop parser shows, the second Received header is bogus (the "by" host in the second Received header doesn't match the "from" host in the first Received header). The chaining is bogus. I am not "crfannon" by a long stretch (only 2 of the letters in that username match those in my username). It looks like the parser is going ahead and munging the To header regardless of it matching my e-mail address in either the e-mail that I sent to SpamCop to report the spam or to the e-mail address recorded under Preferences. Yet, viewing the message shows the original To header with the e-mail address intact so it doesn't make sense why it would be hiding the To e-mail address in one place but not in the other place. Whether I use the tracking URL for the spam previously submitted or I use the copy/paste web form to enter the contents of that old spam, I see: Parser page: To: "Crfannon" <x> View entire message page: To: "Crfannon" <crfannon[at]comcast.net> So the munging isn't working on the "view entire message" page. Good thing that I was never included in the To or Cc headers. I took a random sample of past reports, clicked on one of the number ID links for a recipient included in that report, and clicked the Parse link to get back to the report page. In each case, the "view entire message" page shows the original To header (i.e., it is not munged). However, I am looking at my own reports so it is possible that the "view entire message" page is seeing it is me looking at my reports and so it will show the original contents of the To header. Since you are an admin, maybe the same applies to you. So we need someone other than me who is not an admin to look at some of my past reports to see if the To header under the "View entire message" shows the munged list of recipients or the original (unmunged) list. Some tracking URLs to some of my other reports are: http://www.spamcop.net/sc?id=z759041746z41...0062a75f8c95a4z http://www.spamcop.net/sc?id=z760107693z01...df8be18b192ddcz http://www.spamcop.net/sc?id=z761458963zd0...fdccbd362dad36z When I look at the "View entire message" page, the original (unmunged) e-mail address(es) appear there (but show as one, or more, "<x>" back on the parser page). So hopefully it is because me or an SpamCop admin are looking at my reports that they can see the original list of To recipients. If I login into SpamCop using the account under which I submitted the spam report, the "View entire message" page shows the original (unmunged) list of recipients in the To header. If I login in under a different SpamCcop than the one used to submit my prior spam report, the "View entire message" link isn't even there. If I don't login at all, the "View entire message" link is there but the recipient list in the To header are munged. Or, alternatively looking at the login status: If I login under my own account (or admin under their account), the "View entire message" will show an unmunged list of recipients. If someone is logged under their own account (which is NOT an admin account), they don't even get the "View entire message" link. If the user is not logged in at all, the "View entire message" will show a munged list of recipients (same as shown on the parser page). So that explains why you see a difference between the parser and "View entire message" page because, as an admin user, you get to see the same stuff that I see but which no one else gets to see. As to me being listed anywhere in the headers or body of the spam message, sometimes I am but usually I am not. As mentioned in my prior post, I don't have to be in any header in order for the e-mail to get routed to me.
  19. As the recipient, I have no control over what the sender put in those fields. While the From header is mandatory (must appear once and only once), we all know it can contain whatever the sender wants to put in it. Regarding the To header, you actually get a lot of spam with you in the To or Cc headers? That is part of the *data* that the sender composes and as such the sender can specify any string they want which may not even be a validly syntaxed e-mail address. The To header is optional: it may appear zero or one times. It is part of the sender's data (i.e., the sender can put whatever they want in there) because it is NOT used to deliver the message. The RCPT-TO command issued by the sender is what determines to whom the e-mail gets sent. Very few spams that I receive ever list me in the To or Cc headers (and obviously I would never be listed there if they used Bcc instead of using bogus To, Cc, and Bcc fields and their e-mail client issued the RCPT-TO command based on an external recipient list, as happens with listservers). The problem with codebox is that it uses the DIV tag but its style attribute does not include a width element. If the style element (for DIV) cannot specify width then a 1-row, 1-column TABLE should be used within the DIV tag which can use the WIDTH attribute and which is a percentage of the window width. That's a bug in the HTML code generated by this BB software for the codebox tag: no width control by percentage. By the way, Wazoo, I followed your steps in how to copy/paste the spam message into the submit web form. Using that method, and after selecting the extra recipients, I did see the e-mails for those extra recipients in the Preview listing. I'll have to check what happens next time when I use the e-mail method to submit spam reports. As regards to munging, just what gets unmunged in the e-mail sent to those recipients that refuse munged spam reports? When using the copy/paste web form method for submission to SpamCop (so I could see the munge-refusing recipient's copy of the spam report to get sent to them), I saw my IP address in the Received header (but that is included in the munged reports, too) and can't see anything else that got unmunged to reveal me. In the unmunged version of the e-mail sent to the recipient, and besides the IP address which is included in munged and unmunged reports sent out, I couldn't see anything of "me" identified in the unmunged e-mail in its headers or in the short prelude info added by SpamCop. I saw my SpamCop account name in the From header but I can change that to anything I want in Preferences (it's now "Lee H" instead of "Hodsdon"). Does SpamCop go hunting through the headers looking for my e-mail address in the headers and body to alter it for the munged reports? If so, how does it know which of my e-mail addresses to use? The one and only one registered under Preferences in my SpamCop account? If so, that's just one e-mail address. As I've seen, a SpamCop user can report spams received at any of several of their accounts through their one SpamCop account. Originally I created 2 SpamCop accounts (and would've created 5 total for all my accounts) except I was led to believe that is unnecessary. I would have to deliberately NOT save the SpamCop cookie so I would be forced to login each time. However, I would then have to go back to my e-mail client to see through which e-mail account the spam was received. As noted above, my e-mail address where I receive the spam may never be listed anywhere in the spam headers or body. Should I be creating a separate SpamCop account for each of my e-mail accounts and NOT save the cookie so that I am forced to login again each time depending on through which e-mail account that I received the spam? The only e-mail address of mine that SpamCop might ever see in a spam report is the one recorded under my Preferences (i.e., it isn't anywhere in the spam itself). However, the spam report that I send to SpamCop will have my true e-mail address since I don't munge or falsify those headers; i.e., when I send e-mails, the From and/or Reply-To headers are correct. I munge my e-mail address in newsgroup posts but not when I send e-mails.
  20. Sorry, had to slice up the lines in the quote above since word wrap seemed to be dead and made the width ridiculously long. UPDATE: Oops, looks like the codebox doesn't work very well for horizontal scrolling. One line in the spam body was long and codebox provided a scrollbar but only for a small portion of the maximum line length. The Preview page looked okay but not the submitted post. I sliced up the long line to compensate for the codebox BB tag defect. UPDATE: Too many long lines. I'm not going to bother editing them all because of a defect with the horizontal scrolling for the codebox BB tag. Pre-munged? How? Where? My e-mail address is not shown but then it never needs to be included in any header. The spammer's client issues the RCPT-TO command to their SMTP server and that is who gets the spam, not whomever is listed in the From header (since that is part of the *data* sent in the DATA command). I right-click and send the spam as an attachment to SpamCop. I have several accounts but apparently SpamCop doesn't match up my e-mail address (in the headers of the e-mail that I send them with the spam attached) but merely uses the cookie for auto-login, so all spams in all e-mail accounts get reported through the last logged in SpamCop account. I did create another SpamCop account for another e-mail account figuring, at one time, that I needed a separate SpamCop account for each e-mail address from which I report spam but that appears not to be a requirement. The cookie always logs me in to the same last-used SpamCop account. What in the spam that I got which was attached to my spam report sent to SpamCop was munged (by me)? Below is a copy of the original spam message sent as an attachment in my spam report e-mail to SpamCop (the loss of blank lines is a defect of the codebox BB tag): From: "Trevor Crouch" <Nwsasfs <at> offenburger.com> To: "Crfannon" <crfannon <at> comcast.net> EDIT: "codebox" issue resolved by deleting unnecessary data, also munged the exposed addresses
  21. After looking at datestamps in some logfiles and using them to see which SpamCop reply got delivered close to then, and then digging around in my e-mail clients (good thing it was in Outlook since I configure OE to flush the Deleted Items folder on exit), I think I found the URL to the submission page where I select the recicpients for the spam report. It was: http://www.spamcop.net/sc?id=z762328415z59...a8a1eabd4b5d54z I don't see a means of resubmitting the report in order to get the checkboxes again regarding which recipient gets a copy so I could then select the one that wouldn't accept unmunged reports, okay the warning prompt, and then use Preview to see if their unmunged e-mail were shown in the list. Also, and this is from memory, after looking at the preview listing and returning to the screen with the checkboxes for recipients and when I complete the submission, those extra checkboxes that I had selected (and were NOT pre-selected by SpamCop) were cleared, so I had to select them again. However, since I couldn't see the unmunged e-mail copy in the preview listing that would go to the picky Gaoland address (one Gaoland address refuses, the other Gaoland addresses accept), I chose not to send them the unmunged version of the e-mail. I couldn't see it so I didn't include that recipient. I did, however, have to reselect the missed-spam[at]comcast.net and spam[at]uce.gov recipients. The order in which I performed the actions were: - Send the spam as an attachment in an e-mail sent to my "submit" e-mail address at SpamCop. - Get back a reply from SpamCop with the URL to the submission web page. - Select some extra recipients beyond those already pre-selected by SpamCop. - When selecting the first recipient that doesn't accept munged reports, a popup appears saying such and I have to okay the selection. I okay it so the extra no-munge recipient gets selected. - Click on Preview and scan through each e-mail copy to find where the no-munge recipient's version of the report is shown. It isn't shown. None of the e-mails for the extra recipients are shown, munged or not. - Exit the preview and return to the submission page. All the extra recipients have been cleared. I have to reselect them (except for the no-munge recipient since I won't be sending an unknown message to them). - Submit. - I can look in Past Reports but none of them show the report ID and they all just show the originally reported spam instead of the e-mail that actually got sent to that recipient.
  22. Okay, clue me in. I click the link for Past Reports. That presents me with a page where I can enter a report ID (but I don't have one) or a link for "View past reports". I click on "View past reports" and what I see are groupings of recipients where each group is for a spam report. The link for each recipient listed there (the numeric link on the leftside, not the e-mail link on the rightside) just shows me the original spam that I reported to SpamCop. It is NOT a copy of the report that actually got sent to that recipient. If the numeric link in the list of past reports is the report ID, why is it different for each recipient? How would I use that numeric value in a URL to actually get back to the report ID? Since the content shown by each numeric link is simply what I originally submitted to SpamCop as the spam message, there is no report ID or anything else added by SpamCop in there. What I see when I visit the past reports page is: Submitted: Wednesday, May 11, 2005 11:53:57 AM -0500: **spam BAYESIAN_PLUGIN BODY** light Bretylium Tosylate In Dextrose 1422523481 ( Forwarded spam ) To: spam[at]uce.gov 1422523465 ( 80.119.97.20 ) To: postmaster#gaoland.net[at]devnull.spamcop.net 1422523446 ( 80.119.97.20 ) To: spamcop[at]imaphost.com 1422523411 ( 80.119.97.20 ) To: missed-spam[at]comcast.net 1422523402 ( 80.119.97.20 ) To: dom_tech[at]gaoland.net 1422523338 ( 80.119.97.20 ) To: abuse[at]teleglobe.com (The "**spam BAYESIAN_PLUGIN BODY" was a prefex tag added by SpamPal. I use it in my rules to differentiate that spam and handle it differently from other spam detected by DNSBLs or other plug-ins from SpamPal.) The recipient that would not accept munged reports was for one of the contacts listed for gaoland.net. I think there were 2, or more, listed for Gaoland and only one would accept munged reports. Selecting the other one resulted in the popup warning about sending an unmunged report to them. I okayed that dialog to select that recipient and used Preview to see what they would get but that recipient's e-mail copy was not included in the preview listing.
  23. I'm not concernced about my IP address being in the Received header. That only identifies me as a customer of my ISP, not my e-mail address. If they want to go to the effort of filing charges, submitting a request and getting a court order, and making my ISP divulge who I am then let them do that. I'm not trying to hide in order to eliminate responsibility for my actions. I don't want them to get my true e-mail address in case the spam report hits the spammer; i.e., I'm not interested in ever qualifying my e-mail address to the spammer to get even more spam from them or to whomever they sell their "active" list of e-mail addresses. As I understand it, it they want to contact me, even for a munged report, they can still do that. The From line in the munged reports is no biggie, either. That is my moniker as defined under Preferences and I can change that so it doesn't reflect my name, or just uses my firstname (and maybe a lastname initial). The list of e-mails shown in the Preview window is, as you say, quite long. I scrolled all the way to the bottom. Each e-mail is separated by a double row of number characters ("#") so it is easy to find the start of each message. I only showed one instance of the e-mail (a munged one) because that was the format for each message. They all looked the same except for the difference of who was the recipient. That's why I showed a template of each e-mail. I didn't see the point of repeatedly showing the same munged report going to 5 recipients. However, although I selected the recipient which will not accept munged reports, I couldn't find an e-mail version that would be going to them. In fact, I don't recall seeing a version of the e-mail shown for any *extra* recipients that I selected. The Preview list showed only the list of recipients that SpamCop had already pre-selected for me. When I view my past reports, it only shows me a copy of each e-mail that got sent to each recipient. In this case, and because I couldn't see what the unmunged report looked like, and because I then chose to not send an unmunged report, none of those e-mails were for that recipient. Also, the Past Reports list only shows the content of the spam that I originally reported to SpamCop. Its does NOT show me the headers and message that get added in the actual report sent from SpamCop that the recipient will actually receive. What I see is the spam that I reported, not what the recipient gets. Also, the Past Reports list does NOT show the SpamCop reporting number. Although the first page when selecting the Past Reports page shows a "Report ID" input textbox to jump directly to that report, going to the "View recent reports" page doesn't list any of those report identifiers. I can't give you a report ID because it won't even tell me what it is. I did scroll through the entire list of e-mails shown in the Preview list. None of them were for the extra recipients that I selected. The only recipients listed were those that were already selected when SpamCop presented its page where I complete the submission. That is, only the default recipients already pre-selected by SpamCop would show up in the Preview list. The other recipients that I have to select were not included in the Preview list. Does the Preview still work *after* the submission has completed (i.e., after I complete the submission and the reports go out)? Otherwise, I'm not sure what good is knowing the report ID if the Preview function is no longer available for a submission already completed. Also, how do I get a list of the report IDs rather than a grouped listing which only shows the originally reported spam for Past Reports?
  24. I finally got a spam that when reported has SpamCop say that one of the recipients won't accept munged reports. The recipient is not selected by default and you get a popup warning when you select that recipient. So I selected the receipient (along with others that were already selected) and used the Preview button. The version of the e-mail that will get sent unmunged was NOT shown. I got the following: ############################################## (Recipient:default_selected_recipient) Received: from [my_IP_address] by spamcop.net with HTTP; Wed, 11 May 2005 17:11:51 GMT From: "myname" <preview[at]reports.spamcop.net> To: default_selected_recipient Subject: spamcop_tag orig_subject_text more_headers message_body ############################################## For each recipient that SpamCop selected by default (i.e., they were already selected when I got to the submit web page), there was the above item listed showing what the recipient would receive. However, none of the other recipients that I selected were included, so those that I had to manually select who refuse munged reports were not shown in the preview. So I really don't know what they get. The Preview will not show each recipient selected by the user. It only shows the default selections already made by SpamCop. Presumably the same report gets sent to the munge-refusing recipient but with my e-mail address in the From header. However, that would be the e-mail address under which I logged into SpamCop, and might not be the e-mail address to which the spam was actually delivered. I have 2 SpamCop accounts but the login with cookies only remembers the last login. So typically I end up reporting spams received in Outlook (for one set of 3 accounts) and spams received in Outlook Express (for 2 accounts solely for newsgroups and forums) through the same SpamCop account. What e-mail address actually gets put in the From header for the unmunged report? Since the e-mail address to which the spam was sent and received might not even include my e-mail address, I have to assume that my SpamCop account's e-mail address gets used. That means I could be sending an unmunged report which claims it was for an e-mail address but which was not the one where the spam was actually received. Yeah, it's a small point and probably doesn't alter the fact that spam is getting reported regardless of which e-mail address it hit, but if it is to be unmunged then I don't want to be lying about to which account the spam got received. I would have to logout and log back in under the appropriate SpamCop account to get the correct e-mail address listed. I change the e-mail address for returning SpamCop reports but I don't know if that is also the same e-mail address used in unmunged reports sent out from SpamCop (since I can't see what the unmunged report will look like using Preview). I could abandon my current SpamCop account and create a new one where I use an alias, like through Sneakemail and then kill that alias (after changing the e-mail in the Preference setting) to eliminate divulging my true e-mail address. I might leave the alias alive simply to see if it ever starts getting spammed as a result of sending unmunged spam reports.
  25. I do have munging (obfuscation) enabled in preferences. I must've missed there was a Preview button. But when using it, which version of the e-mail will it show me? When I send the spam report, it may go to several recipients. Some are recorded as refusing munged reports. If you elect to send to them anyway, your information is no longer munged. But is it just for the copy sent to that particular recipient or do all recipients get the same copy with the unmunged data? The Preview may only show me one view of the spam report. If there is only one view of it to see then my unmunged data is going to all recipients. I'll have to wait until the next spam gets reported to see what is presented when looking at the Preview display (and also have to wait until I happen to send to a recipient that refuses munged reports to see if the Preview shows 2 separate versions of my spam report).
×