Hello all-
I've just started noticing these errors in my log. I realize that the error code tells me that there is no domain information available for the return path search, but is the IP in the message the relevant IP, or is it the IP being queried?
The 'return path' is not an IP address at all, it is the email address used in SMTP to identify the sender. SIMS verifies the return path by looking for the domain part of the return path in DNS, first looking for an MX record and then if no MX exists, looking for an A record. If the A lookup fails, you get an error message like the ones you cite, and it is generally the only level 3 message associated with that attempt to send you mail from a bogus source.
Or am I receiving information about another search and I just don't have the logs turned up high enough to see it?
If you turned up logging you'd see something like this:
03:18:04 4 SMTP-924(ACB47D4A.ipt.aol.com) Input Line: MAIL FROM: <[EMAIL PROTECTED]>\r
03:18:04 5 SMTP-924(ACB47D4A.ipt.aol.com) *Status=25
03:18:04 5 SMTP-924(ACB47D4A.ipt.aol.com) *Status=26
03:18:34 5 SMTP-924(ACB47D4A.ipt.aol.com) Disconnect Received
03:18:34 5 SMTP-924(ACB47D4A.ipt.aol.com) Disconnect Confirmed
03:18:51 4 SMTP-924(ACB47D4A.ipt.aol.com) No relay exists for 'genie.com'
03:18:51 4 SMTP-924(ACB47D4A.ipt.aol.com) Looking for genie.com
03:19:39 3 SMTP-924(ACB47D4A.ipt.aol.com) Return-Path-A Search Error. Error Code=-3162
03:19:39 4 SMTP-924(ACB47D4A.ipt.aol.com) Sending 572 <[EMAIL PROTECTED]> cannot be verified now\r\n
Notre that in this case, the MX lookup took 47 seconds to fail, but the spammer got impatient 30 seconds in and hung up. SIMS still did the A lookup (for good reason) but in 48 seconds that failed too.
The reason the A lookup is still wise after the MX query fails is this timing issue. A domain with no MX can still have an A record and so be a validly deliverable domain, even if it is badly served by DNS. If the A lookup succeeds but the sending side has given up for slowness, then the next time the sending side tries to deliver the same message there is a strong chance that the old query will have yielded a result that remains in the local cache, resulting in swifter response.
If I'm getting all of these hits from the below IP addy (which has very little info available about it in my ARIN search) I was going to just blacklist it, but I don't want to blacklist an IP if I don't need to.
You don't need to blacklist this address unless you see mail being accepted from it, which would imply that the spammer(s) using it have risen from amoeba to slime mold in their intelligence level. In the cited log lines you are seeing mail from it being rejected 3 times in 33 minutes.
A little research indicates that this machine was probably a mail server with either cracked SMTP AUTH. It is not currently answering on port 25, so it is likely fixed.
--
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]>
