SIMS puts the target address domain name into the parentheses, not the hostname of the MX being used. Any mail to any *@RobertMondavi.com address would get its SMTP connections marked like that, even though the machine being spoken to has some other name.On 11/13/02 at 16:51, Roger Corbin wrote:We have a problem where we cannot send mail to one domain. There are no problems sending to anyone else just this one. We can however receive mail from that domain.This is the message that comes up in the log when trying to send to that domain. 10:12:22 3 SMTP-339(RobertMondavi.com) Expected 250 <id>, got 554 No SMTP service here\r 10:12:22 3 SMTP [S.0001978312] dequeueing 10:12:22 3 SMTP [S.0001978350] dequeueing Any idea what might be up ?Looks like SIMS is trying to make an SMTP connection to RobertMondavi.com and it gets a 554 result code from the remote host, as logged above. I'm not sure why SIMS is trying to send to RobertMondavi.com, though, as the MX for that domain is napa-mailflt.robertmondavi.com:
% dig RobertMondavi.com. mx
;; ANSWER SECTION:
robertmondavi.com. 12H IN MX 200 smtp-relay.pbi.net.
robertmondavi.com. 12H IN MX 100 napa-mailflt.robertmondavi.com.
When I telnet to napa-mailflt.robertmondavi.com on port 25, it answers
appropriately (although it gives a somewhat unorthodox greeting banner):
% telnet napa-mailflt.robertmondavi.com 25
Trying 206.171.2.219...
Connected to napa-mailflt.robertmondavi.com.
Escape character is '^]'.
220 *****************************************************0************
helo pluto.homes-magazine.com
250 napa-mailflt.robertmondavi.com Hello pluto.homes-magazine.com
(216.111.116.95)
rset
250 State reset
quit
221 napa-mailflt.robertmondavi.com closing connection
Connection closed by foreign host.
Is there more of the conversation between your SIMS and RobertMondavi.com
in your log? Try turning up the SMTP logging level to capture more detail
about it.
However, I think that I have a *guess* as to what is happening, even with just the level-3 log entry.
That banner full of asterisks is typical of an MTA 'protected' by the 'SMTP fixup feature' of a Cisco PIX firewall. I enquote those words because in fact, that behavior is no protection, fixes nothing that should ever need fixing, and is definitely not a feature but a sure way to break and hide proper MTA behavior. Whoever at Cisco came up with that abomination should be fired and forced to look for an IT job in rural Mississippi.
The error seen in SIMS indicates that SIMS was expecting a '250 <id>' response. That would not be an initial banner, but the response to having sent a message, which is typically responded to by an MTA with '250 <Message-ID> accepted for delivery' or some similar line. The 554 response actually received cannot be trusted to mean what it says beyond the 5xx code, since the PIX plays games with the specific numbering and the associated text message.
--
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]>
