[antispam-f] Re: missing headers
- From: Richard Porter <ricp@xxxxxxxxxxxxxxxx>
- To: antispam@xxxxxxxxxxxxx
- Date: Thu, 13 Sep 2007 00:52:09 +0100
On 12 Sep 2007 Jeremy Nicoll - freelists wrote:
> Richard Porter <ricp@xxxxxxxxxxxxxxxx> wrote:
> I don't see any reason why SpamStamp would "chop" anything, ever.
Neither do I, but it has to process the message in order to add its
headers in the right place.
>>> Could you zip up the whole of the relevant logs, and the whole of the
>>> backup file etc and send them to me? I find it hard to picture EXACTLY
>>> what is where from your descriptions.
>> I think you have all of the relevant bits of the log and the whole of
>> the backup file. The only bits I chopped out were as marked.
> No-one apart from you has seen the backup file.
I have stated that the backup file contains exactly what was seen in
Messenger, plus the header line which I also quoted in full. If that
wasn't clear enough here it is:
#! rmail 0000530
X-AntiSpam-Date: Tue, 11 Sep 2007 00:45:57 +0100
X-AntiSpam-Action: default
We are looking for a highly motivated professional, with skill of
working with people. The position is home-based. We offer a part-time
position with flexible working hours. And we would be happy to
consider a full-time job share applicant.
The right person will have good consultation and interpersonal skills
and some knowledge of advertising. Candidates must be able to keep on
focused and motivated when working alone.
Spam: Yes
SpamScore: 100.00%
Note that the "blank" line actually contains a space, so SpamStamp
didn't recognise it as the end of the headers.
>>> Pity; I used to keep 20 generations of backups...
>> SS is set to keep 10 backup copies but I can't find where it stores
>> them.
> You should try and find out (from JJvdG) so that next time, if there is a
> next time, you can rescue the backups.
HANG ON A MINUTE!
I've been following a false trail. The spurious message was processed
by AntiSpam at 00:45:57 on the 11th. The matching message was received
at 16:36:05 on the 10th and was processed normally. It contained a lot
more text both before and after what you see above. The log at the end
of the 00:45:55 session looks like this:
[rest of headers not shown but unexceptional]
< Subject*proud, 0.99000
<
< In other applications of carbon nanotubes, Dai has Professor Michael
McGehee is developing cheap and efficient nanostructured solar cells.
<
< Hello,
< First and Primarily, we would kindly like to convey our deep
greetings to you and your family and wish you all good condition and
happiness and more success in business. Our International Corporation
in search of new employees on different vacancies.
< We are by now for a long time in the market and now we employ human
resources to work from home.
<
< Our Corporation Head Office is located in United Kingdom with
branches all over the world. Our supreme desire now is to expand our
business level to more countries, so we are advertising here in hope
of cooperating with you all. We be grateful for ho
< nest and ingenious employers. You do not need to spend any sum of
money and we do not ask you to give us with your bank account number!
We are engaged in totally legal activity and working in our company
you can reach career growth at a permanent job
< .
Message 1 accepted by default
From: "elvin duncan" <gail@xxxxxxx>
Subject: If you want to make a carrier in a successful company - we
are proud to invite you in our business.
> RETR 1
<
> DELE 1
< +OK 5168 octets follow.
> QUIT
< X-Daemon-Classification: INNOCENT
Messages accepted on rules: 0
Messages accepted by default: 1
Headers downloaded on rules: 0
Messages deleted: 0
Messages deferred: 0
Messages diverted: 0
Terminating at Tue, 11 Sep 2007 00:45:57
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This is definitely dodgy. The ten body lines had not been received
when AS sent the RETR request. The server carries on sending body
lines (the next one is blank), AS decides there are no octets to
follow and sends a delete request. Now the server responds to the RETR
request but AS is out of kilter and sends back a QUIT. At some point
either the server sends back some random data which happen to be part
of an earlier message, or AS thinks it has received a message and
picks up some random data locally and bundles it off to the defaulted
directory.
So was it abnormal behaviour by the server, or did something in the
last message cause AS to get its knickers in a twist? Unfortunately
because that message was deleted and not stored I can't check. However
note that fewer that 10 body lines were returned and that there were
some very long lines (one was 501 characters) which were split in the
log file.
I would guess that AS is assuming that it has received a valid
response to the POP commands without checking and/or there's a buffer
overflow because AS isn't expecting a long line of text in response to
a POP command.
--
_
|_|. _ Richard Porter http://www.minijem.plus.com/
|\_||_ mailto:ricp@xxxxxxxxxxxxxxxx
Other related posts:
