Search the Community
Showing results for tags 'parsing'.
Found 3 results
-
SPAMCOP report results I have tried both manually processing this email AND as an emailed submission via my account. SpamCop chokes on both.
-
I can't report this spam (without body can be reported) Received: from 193-109-128-190.ukrcom.kherson.ua ([193.109.128.190]) by mail.atlascon.cz with ESMTP for x; Thu, 23 Nov 2017 10:34:13 +0100 Return-Path: best_medications1@kherson.ua From: Drugs Drugstore <best_medications1@kherson.ua> To: x Subject: HIGH-QUALITY MEDS for the LOWEST PRICE, Tarah240 . Date: Thu, 23 Nov 2017 12:34:15 +0300 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
-
I have had a few spams recently (windward casino) that spamcop gave error message: at the end of "Finding links in message body" I did some exploration, and discovered that the problem seems to be the way the spam emails are constructed. They are multipart/alternative, and the alternative header blocks are ending with a line containing a single space. Deleting that space in the body of the content lets spamcop parse the body correctly. --Section.«guid» Content-Type: text/plain Winward Casino: US Players, … That *blank* line is really a space. Deleting the space character allows the "Finding links" to work again. Example: https://www.spamcop.net/sc?id=z6408256844z01c6f10262d93f7fd6bc56e589ea4e33z I understand that the original purpose of that message, was due to an error in the user handling the copy/paste/forward of the emails in such a way that email header was no longer accurate. However, in this case, the "couldn't parse head" is really the multipart header in the body of the message. That was not really clear from the context.
