[SGVLUG] Automating (scripting) telnet

[Emerson, Tom]

I have a small fetchmail problem.  Every now and then, I get a bit of spam with a "from" line that looks like this:

   from: "steven"" <some.email at some.server>

Note the extra "quote" character -- that causes fetchmail to puke.  I believe this is "fixed" in later releases of fetchmail, but I don't have ready access to a binary for it (and the dependancy chain to compile it is more than I want to deal with at the moment)

As it is, I've been "dealing" with this problem by logging in to my e-mail server using telnet and manually finding-and-deleting the message.  Normally, this is the first message in the queue, so there isn't much of a problem.  Unfortunately, after I clear the first one, there *may* be a second one that has arrived in the following 900+ queued messages [and in fact, that is exactly what happened this morning: message 671 was the same bit of spam...]  Normally, when fetchmail runs it deletes messages it has processed, but in the case of this "bad" message, fetchmail seems to drop out entirely (forcibly disconnect?) and as a result, the 670 messages that it had reported as "flushed" aren't actually flushed, meaning that fetchmail will retrieve them again on the next cycle.

when the second (or third, fourth, or fifth...) copy arrives within say the first 50-60 messages, it isn't too difficult to manually type "dele <nn>" for each message, but when there are 600+, well, I know my fingers will get tired...

What I'd like to do is somehow "script" telent so that I can delete those 600+ messages that have already been processed, something like this:


[I type]
  $  killmsgs 670

[it does this]

   telnet <my.providers.pop.server> pop3
   user <me>
   pass <mypass>
   dele 1
   dele 2
   ...
   dele 670
   quit

If I just "feed" this to telnet, i.e., "telnet <cmds", it doesn't work -- telnet doesn't seem to "wait" for the server to actually be "ready for input" before sending the commands -- it might see "user <me>", for instance, but only get "last-half-of-password>" as the next "command" since my client would have started sending it before the server responded with "OK, hello <you><crlf>".

any thoughts?