Jump to content

jrcovert

Members
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jrcovert

  • Rank
    Member
  1. jrcovert

    ipv6

    The last header is always introduced by the last machine. But this is not at all the same as if it were an internal transfer on a 10.x.x.x address. The header is: Received: from 2flagg (2001:748:100:40::2:6) by 2flagg.covert.org (V5.5-11, OpenVMS V8.2 Alpha); Fri, 6 Nov 2009 05:54:55 -0500 (EST) 2001:748:100:40::2:6 is not an internal address; it's the address of the remote machine which relayed the spam to me (mout4.freenet.de). If you don't process that, you don't know that some spammer at 2001:748:100:40::2:6 didn't fabricate the rest of the headers. The reverse translation (which you ignore anyway when you process headers) is not the actual one due to the fact that I'm running VMS V8.2 on THAT particular machine (and have been since it was installed 4 1/2 years ago: Uptime 1625 21:34:26), an AlphaStation 200 4/233. My other gateway is running 8.4 (AlphaStation 255/300) and produces headers like this: Received: from wb2flw.octothorp.org (2001:470:80ee:0:215:c5ff:fe06:ab40) by covert.covert.org (V5.6-ECO3, OpenVMS V8.3 Alpha); Sun, 8 Nov 2009 18:00:26 -0500 (EST) As I'm sure you know, if you don't process the final header, you have no way of knowing for sure that the header before it is valid or not. Theoretically, my buddy at wb2flw.octothorp.org could be a spammer, and could have created all of the bogus headers before the IPv6. Similarly, unless you actually process the address 2001:748:100:40::2:6 both backwards AND forwards (a spammer could have a bogus reverse translation for his IPv6 origin just like he could for his IPv4 origin), you can't relate it to the other headers. In the case of the report for message number z3473686828z187e363e622e99ddcfe41259329adc9bz, you trusted the first header beyond the one for the arrival at my machine: Received: from [195.4.92.12] (helo=2.mx.freenet.de) by mout4.freenet.de with esmtpa (ID hijgdt[at]bossmail.de) (port 25) (Exim 4.69 #92) id 1N6MSB-000438-Qz; Fri, 06 Nov 2009 11:54:03 +0100 Fortunately, this one IS an "internal" header added at freenet.de, so the rest of your analysis was OK. If the spammer had connected directly to me, he could have caused the analysis to be wrong, and pointed a spamfinger at someone not even involved, generating a false report. /john
  2. jrcovert

    ipv6

    I'm seeing more IPv6 spam lately. These recent ones all come from freenet.de, but it should not be that much work to recognize the received header correctly. In all of the messages below, the header for the arrival by IPv6 at my system is being ignored, and spamcop begins processing with the next header. Since it seems that freenet.de is adding another valid header when it receives the message, there is something for spamcop to work with, but the assumption that the top header isn't valid is unfortunate. http://www.spamcop.net/sc?id=z3107858845z1...eb60437ec2b504z X-First-Received: from 2flagg (2001:748:100:40::2:6) X-Received-Time: Sat, 11 Jul 2009 21:22:59 -0400 (EDT) $ host 2001:748:100:40::2:6 6.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout4.freenet.de. *************** http://www.spamcop.net/sc?id=z3277377851zb...1e8ca75c06488fz X-First-Received: from 2flagg (2001:748:100:40::2:8) X-Received-Time: Tue, 1 Sep 2009 05:02:11 -0400 (EDT) $ host 2001:748:100:40::2:8 8.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout6.freenet.de. *************** http://www.spamcop.net/sc?id=z3279340826zc...7a6c1eb91472ccz X-First-Received: from 2flagg (2001:748:100:40::2:5) X-Received-Time: Wed, 2 Sep 2009 00:13:28 -0400 (EDT) $ host 2001:748:100:40::2:5 5.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout3.freenet.de. *************** http://www.spamcop.net/sc?id=z3457351375zf...c7ae5d8c54ea21z X-First-Received: from 2flagg (2001:748:100:40::2:3) X-Received-Time: Sat, 31 Oct 2009 10:58:45 -0400 (EDT) $ host 2001:748:100:40::2:3 3.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout1.freenet.de. *************** http://www.spamcop.net/sc?id=z3473686828z1...e41259329adc9bz X-First-Received: from 2flagg (2001:748:100:40::2:6) X-Received-Time: Fri, 6 Nov 2009 05:54:55 -0500 (EST) $ host 2001:748:100:40::2:6 6.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.1.0.8.4.7.0.1.0.0.2.ip6.arpa domain name pointer mout4.freenet.de.
  3. jrcovert

    Avtech Direct

    Moved out of the Help Forum, [link here]. Many of us have received "offers" from Avtech Direct. Here's the latest one I received: [spamCop Display] I get these from this particular spammer all the time since I'm on a number of email lists at GaTech and MIT. (I'm a volunteer at both institutions.) SpamCop properly reported both URLs in the message I received today, but as you know I'm using a mail system that's guaranteed not to modify the message before submission to SpamCop. :-) Am I too far off topic to discuss this particular spammer, rather than an actual SpamCop issue? The messages would seem to make it look like this spammer is in full compliance with the [You]CanSpam Act. No obvious spoofing of return address, "ADV:" in the subject, a "working" removal address, a physical postal address. All the right stuff. BUT the spam is coming from (apparently) co-opted servers, sending HELO messages (at least in the case of the messages sent to MIT) with a fake IP address (which doesn't fool the MIT servers) and a fake header claiming to be that fake MIT IP address with another fake server to try to fool the reporting system (SpamCop isn't fooled by this). THAT _is_ a violation of the [You]CanSpam Act. Not to mention the fact that the addresses they're sending to could only have been obtained by harvesting or dictionary attacks. Sometimes I feel like trying to organize the students who have also received these particular spams to each go to a real pay phone and call the 800 number listed in the spam and ask a few legitimate questions about the stuff being sold, and then say "Very interesting, but I would never buy from a spammer." (800 calls from payphones cost the recipient a minimum of fifty cents in addition to whatever rate they're able to get from their phone company.) /john
  4. jrcovert

    website not being LARTed

    Since I received almost exactly the same spam as the original poster (albeit from a different server and with slightly different MIME headers), I did some comparison. What I see is interesting. If you compare the message from the OP: http://www.spamcop.net/sc?id=z658325043z4f...&action=display with the message I received: http://www.spamcop.net/sc?id=z673154943z75...&action=display The thing I find interesting are these two lines in the unmodified original: Call Avtech Direct 1-800-884-9510 before 5 P.M. Wednesday, September 22, 2= 004 Note that the MIME-Encoding is quoted-printable. In the message I reported, the content is still in quoted-printable form, as indicated by the "2004" being split across lines with the "=". However, in the OP's message as reported, that has been reformatted to: Call Avtech Direct 1-800-884-9510 before 5 P.M. Tuesday, September 14, 2004 I wish there were more quoted-printable things (more "=", the "quoting" character used by quoted-printable) in the message to prove my hypothesis, but it sure looks to me like something along the line removed the actual quoted printable material from between the MIME headers and the boundary marker: --EC95.43A.7_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable --EC95.43A.7_-- As stated before, the message SHOULD be _above_ that MIME end marker, not below it. The question is: did a mail system along the way do this, did the reporting mechanism do this, or did the spammer send it out this way (i.e. since it came via a different server than my message, was it modified before mailing by the spammer)? When this happens, is the body of the message always decoded from the encoding scheme indicated by the MIME headers? /john
  5. jrcovert

    website not being LARTed

    At Wazoo's request (see next reply), I've moved the original contents of this reply to the Lounge. You can read it here. /john
  6. jrcovert

    Parsing HTML part error

    The first blank line ends the headers and begins the body. Indeed, if there had been no blank line at all, any mail system would have considered the whole message to be headers. MIME makes this a little more interesting. There are a lot of mail systems out there, and they may try to do various different things to be forgiving of badly formatted mail. Or not. The VMS mail system has no clue at all about MIME. In fact, it cares very little about most headers. It wants to find the From:, To:, Subject:, and CC: headers, and maybe the Reply-To: header. But only to put that information into its own internal-only headers. Otherwise, as far as it is concerned, the message is just a message, and it really doesn't give a hoot about what are headers and what is body. With one exception. If you have selected the option of causing the headers to be displayed at the bottom of the message, it will search for the first blank line, and display everything after that blank line (including any MIME headers in the body) first, and then insert a line at the bottom ================== RFC 822 Headers ================== And then the headers before the first blank line. But that's only if you select the "put headers at bottom option." Let's first discuss the two messages where the blank line before the first set of MIME headers is missing. Since VMS doesn't care about MIME, it has no problem with the message, and it just displays the text. I imported the message into Netscape Mail to see what Netscape would do with it. Netscape displays only the headers. The message body is completely blank. Why? Well, think about what many MIME messages look like. There are headers at the beginning (among the RFC822 mail headers) that indicate that we've got MIME. One of these might say that the message is a multipart message. If so, then the text which appears after the headers and before the first set of MIME headers in the body is ignored by most mail readers that understand MIME. There is often some text there which advises you to get a mail reader that supports MIME. So it's quite possible that you've received a message like this, and just thought you had a blank message. Or maybe not. After all, although I've received three like this in the past two weeks, this has not been a big problem among the other 2700 messages since I started reporting spam through SpamCop. Now, the other one of the messages, the one with the brackets and spaces around the "Priority:" header. Again, VMS doesn't care. The first blank line is the end of the headers and the beginning of the body, but for VMSmail that's pretty much a "so what?" If I import the message into Netscape mail we find that the funky bad header is simply ignored, as though it wasn't there at all, and the message is displayed "properly". However, since the message is declared to be "multipart/alternative", if you select "View Message as PlainText", you get a blank message, since the alternative part is missing. Hope this has been useful. /john
  7. jrcovert

    Parsing HTML part error

    Just change "members" to "www" and it will work just fine. /john
  8. jrcovert

    Parsing HTML part error

    This is why I usually don't bother with these kind of forums. You guys don't know me from Adam, and you assume that I'm wrong. It's a bit insulting, but it's the way these forums work, so I bear no malice towards you for your skepticism. But I have been an email developer; I work in the VMS development group; I've been using VMS mail and developing other mail systems to interact with it since before many of you were born; and I know exactly how the internals of VMS mail work. VMS keeps those headers completely separate from the message; as I mentioned in a previous message, FORWARD/NOHEADER will send the mail EXACTLY as received from the spammer. I'll tell you about the _one_ exception, just because you've all been so polite: If a mail message, in violation of RFC822, contains headers longer than 256 characters without including the required (by the RFC) return and whitespace, VMSmail will wrap that header when storing it internally. But that's not what's happening here. /john
  9. jrcovert

    Parsing HTML part error

    Oh, and Steven, since I don't know where the discussion of the message above is, I don't know if the reason SpamCop would have choked on it was ever determined. As a VMS developer, it's obvious to me. The unwanted line wrapping occurs exactly at column 80. This indicates that you did a cut and paste from a terminal window that was only 80 columns wide. Although VMS mail never modifies the mail, what is displayed on the screen will be affected by your terminal size settings, and cut and paste will not put wrapped lines back together. /john
  10. jrcovert

    Parsing HTML part error

    As I said, I have submitted about 2700 MIME messages. VMSmail does not "handle" MIME attachments at all. You mention "common headers". Those are the VMS internal "From", "To:", "CC:" and "Subj" headers, completely in addition to the RFC822 headers, which are removed, leaving only the message EXACTLY as received, by the FORWARD/NOHEADER command. I assure you, the spammer is sending the email as it is being submitted; there has been no modification at all of the email occurring during the process of the message being received from the spammer, stored in VMSmail, or being submitted by me. As a VMS developer, and one of the original Email developers at DEC (now at HP), I can assure you that I know the above for an absolute fact. /john
  11. jrcovert

    Parsing HTML part error

    The blank line is not "disappearing." Nor is the Priority line (Priority is a valid MIME header) having the "[" added to it. The spammers are SENDING the mail exactly as shown. /john
  12. jrcovert

    Parsing HTML part error

    Ahah! The older one (from 4 Sep) causes the SpamCop parse error for exactly the same two reasons. See z642123189zbb4e55b12212b9430f3805d7a9e5f5e6z /john
  13. jrcovert

    Parsing HTML part error

    Just got another one. I believe this is what was going on with the one I received a few days before the last one. For some reason I haven't been able to locate it again. This produces the same error message for a similar (but different) reason. z663530528z4ad7999b3ef09011c0cd5e2033259226z There are at least two problems with the formatting of this spam: (1) The last RFC 822 header is the X-IP:186.83.67.186 header. It should be followed by a blank line before the ---205... Mime part boundary. (2) The Content-Type is declared to be text/html when it is in fact text/plain. There's a third problem, but it doesn't bother SpamCop: the message is supposedly multipart/alternative, but only one part is provided. So is the right way to report bugs for _me_ to simply send the problem on to deputies, or is it required to discuss it here first and get a non-newbie to report it, or what? (I'm hardly a newbie to SpamCop, only to these forums, and I generally don't have time to get involved in web-based forums, netnews, or email lists). /john
  14. jrcovert

    Parsing HTML part error

    OK, I just did that. It's not the <x-html> tag or lack of a <head></head> after all. What I had to do was pull out the bogus garbage "[", spaces, and "]" around the Priority: Normal header immediately following the Content-Type: multipart/alternative header. SpamCop needs to be at least as forgiving as most mail readers, which I suspect (don't know since I use VMS) would simply ignore a header like that. How do we get this put on a real bug list? /john
  15. jrcovert

    Parsing HTML part error

    Outlook? Friends don't let friends drive Microsoft. The tracking id is: z647984037z9f23509ab60e80f248d757cd40b7811cz The email program is VMSmail. The reporting mechanism is simply a forward of the message content including all RFC822 headers, unmodified. Email is never modified by VMS after receipt or during forwarding, and the idea of an attachment is unknown. This was my 2646th submission to spamcop since I began using the service in March 2002; the problem is definitely the fact that a spammer has created a message which fools Spamcop's parsing. The display page for this message at Spamcop displays the email exactly as the spammer sent it and as I received it, including all spacing, blank lines, etc. It looks like the fact that the spammer left off the HTML <head> tag is what confused SpamCop. /john
×