When I did "View page source" on the cited page, I noticed that the one thing that set the trash entry apart from the others was the presence of line-feed characters in the database entry -- and in particular, the string being used as the hash key for this entry contained a line-feed as well. I'll copy the relevant part of the html source below with "[\n]" to show where actual line feed characters are present -- note that the "=>", which marks the end of the portion being used as the hash key, follows a line-feed:

...<br>jmathis555@aol.com[\n]
To => jmathis555@aol.com[\n]
To jmathis555@aol.com[\n]
...
[download]

This stands out, because if it weren't for this one bogus entry, the whole list of one-line strings with "delete" links would have shown up in the html source with no line-feed characters at all. (Wouldn't it be worthwhile just to include a "\n" after each "delete" anchor tag in the html source? Makes it easier to "debug" the output...)

Anyway, I'm wondering whether having the line-feed in the parameter string that is assigned to the 'href="..."' part of the "delete" link might have something to do with the problem.

If that is the source of the trouble, then one thing you could do to prevent this in the future is to normalize every "\s+" to a single plain space before storing anything in the database, or at least before using a given string as a hash key. (Sorry I can't be more helpful at present.)

update: On closer inspection, I'd bet money that the problem is being caused by having a line-feed as one of the characters in $_ when you include this string in the 'href="..."' parameter string. When I mouse over that "delete" link with the browser, the link target shows up, but only this much of it: "delete.pl?del=jmathis555@aol.com" -- the rest, as shown in the page source ("\nTo"), isn't being sent back by the browser -- the "\n" seems to terminate the link target. Since the last bit ("\nTo") is part of the hash key in your database, you can't get a match.