Ok, so I figured this out and it's cute. (Admittedly, I'm probably
not the only one here who can put two and two together, but...)
Here's what happened:
> fetchmail: POP3< +OK 0
> 9 messages for steve_at_estevez.freeserve.co.uk at pop.pol.net.uk (32281 octets).
> fetchmail: POP3> LIST
> fetchmail: POP3< +OK
> fetchmail: POP3< 1 2955
> fetchmail: POP3< 2 3288
> fetchmail: POP3< 3 3311
> fetchmail: POP3< 4 2609
> fetchmail: POP3< 5 7562
> fetchmail: POP3< 6 3124
> fetchmail: POP3< 7 3490
> fetchmail: POP3< 8 2619
> fetchmail: POP3< 9 3323
> fetchmail: POP3< .
> fetchmail: POP3> TOP 1 99999999
> fetchmail: POP3< +OK
All Normal so far. This command TOP will now send the message with
full headers. Note that since fetchmail occasionally makes decisions
on what to do with a message based upon the headers, it first reads
all the headers in before connecting anywhere.
> reading message 1 of 9 (2955 octets)
> fetchmail: SMTP connect to localhost failed
And here we see that fetchmail has finished reading the headers (and
the blank line that marks the end of the headers) and attempted to
connect to localhost. It couldn't, so it decides to bail. First just
send a QUIT message to the pop server:
> fetchmail: POP3> QUIT
Now read the response:
> fetchmail: POP3< datapool is a DoS attacks kit
Ah, but the POP server wasn't finished sending out the message yet -
shame on fetchmail for not finishing a transaction it started. What
you see here is the first line of that email message that fetchmail
was trying to retrieve. In fact, that email message can be found at
http://www.securityfocus.com/archive/75/198527 -- if it hadn't been
another incidents mailing list message, I might not have figured out
what happened.
----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
Received on Jul 23 2001
Intro
