Below is a snippet of the kind of stuff I find in my Queue. I just deleted the Queue and I already have almost 3000 new messages there already.
Joe
File Name Size From Time Stamp Recipient
S.0000344444 5K [EMAIL PROTECTED] 9:47:19 AM [EMAIL PROTECTED]
S.0000344445 6K [EMAIL PROTECTED] 9:47:21 AM [EMAIL PROTECTED]
S.0000344447 2K [EMAIL PROTECTED] 9:47:21 AM [EMAIL PROTECTED]
S.0000344446 6K [EMAIL PROTECTED] 9:47:23 AM [EMAIL PROTECTED]
S.0000344449 6K [EMAIL PROTECTED] 9:47:25 AM [EMAIL PROTECTED]
S.0000344450 6K [EMAIL PROTECTED] 9:47:27 AM [EMAIL PROTECTED]
These are looking suspiciously like relay probes which are getting some sort of locally generated auto-reply, perhaps a bounce. That's a symptom of SIMS with an 'Unknown' account configured. Some of the ways that spammers use the more arcane forms of email addressing result in addresses that SIMS properly interprets as local account names and will accept if you have an Unknown account configured. The solution is to not have any config for unknown local addresses. It is an approach to MTA management whose time has past, along with open relay and accepting mail from unresolvable domains. Even without the particularly quirky (and technically correct!) way that SIMS handles quoted local part relay attempts, accepting mail for local users that you know do not exist is simply untenable in a world where spammers regularly run dictionary attacks as their primary means of delivery.
There are also some cases where router configs can cause insidious relay holes. A relay tester is unlikely to find these, because the tester probably has no idea what domain names might have 'interesting' routing that opens a way through, but a spammer might well have run across some domain you handle with a routing quirk.
Finally, there is the possibility of SMTP AUTH or POP-before-SMTP compromise. One risk of those methods is that weak or absent passwords make it possible for spammers to crack accounts and so become trusted for relay by your server.
The only way to decipher this is to sift out all of an SMTP session accepting a message and the associated router entries. To start, it looks like snipping out everything for 9:47 AM will reduce you down to a useful time period, then find the entries for one inbound SMTP session (identifiable by the SMTP-### in the log entry where ### is the session number) and figure out exactly what the conversation was. If that doesn't yield obvious clues, you'll have to try to get the 'ROUTER' and 'SYSTEM' lines associated with that mail's arrival and acceptance to figure out what exactly happened.
--
Bill Cole [EMAIL PROTECTED]
############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
