Re: Analysis of an MSN rejection.

From: PA Bear (PABearMVP_at_gmail.com)
Date: 12/28/04 

Date: Mon, 27 Dec 2004 19:52:59 -0500

A very cursory glance at all you posted suggests she was trying to send a
message using an account other than one associated with her ISP (e.g.,
sending from normansmother@yahoo.com whilst connected to pacbel). 

-- 
~PA Bear
N. Miller wrote:
> My mother passed over an email she received from Yahoo! today; a bounce 
> for
> an MSN email address. To begin with, the hear of the message, which is
> similar to so many similar problems reported in these groups over the last
> couple of years that I have been hanging out here:
>
>> Message from  yahoo.com.
>> Unable to deliver message to the following address(es).
>>
>> <..Úser..@msn.com>:
>> 65.54.190.7 does not like recipient.
>> Remote host said: 550 5.7.1 Unable to relay for ..Úser..@msn.com
>> Giving up on 65.54.190.7.
>
> The normal response has been to provide links to MSFT pages about relaying
> errors, and suggest that the sender needs to use their own ISP's SMTP 
> server
> to send the message; but there is more to this than meets the eye. First,
> the system logs of the outbound message:
>
>> Mercury SMTP Server ('S' module):
>> T 20041226 143347 41ce1978 Connection from 192.168.102.101
>> T 20041226 143347 41ce1978 EHLO [192.168.102.101]
>> T 20041226 143348 41ce1978 AUTH LOGIN
>> T 20041226 143348 41ce1978 MAIL FROM: <..Úser..@pacbell.net>
>> T 20041226 143348 41ce1978 RCPT TO: <..Úser..@msn.com>
>> T 20041226 143348 41ce1978 DATA - 102 lines, 3998 bytes.
>> T 20041226 143348 41ce1978 QUIT
>> T 20041226 143348 41ce1978 Connection closed with 192.168.102.101, 1 sec.
>> elapsed.
>
> The client is MS Outlook Express 6; this is the brief log from the SMTP
> server which accepted the message for relay. Yes, the IP address is
> "unroutable". Not really; all IP addresses can be routed, and this one can
> certainly be routed from the computer on which MSOE is running to the
> computer on which Mercury Mail is running. It is an RFC 1918 IP address;
> which only means that it is not to be publicly routed.
>
>> Mercury SMTP Client (relay version) ('C' module):
>> T 20041226 143415 fff9b60f Begin processing job MO00002F from
>> ..Úser..@pacbell.net
>> T 20041226 143415 fff9b60f Job MO00002F from ..Úser..@pacbell.net
>> processed OK.
>
> This is the brief log of the message being sent from Mercury Mail to the 
> ISP
> SMTP server. I did not have session logging turned on, so I don't have the
> full session to show. I had my mother resend the message later so I could
> get a session log:
>
>> 23:45:06.601: --- Sun Dec 26 23:45:06 2004 ---
>> 23:45:06.601: Connect to 'smtp.pacbell.yahoo.com', timeout 30.
>> 23:45:07.183: >> 220 smtp812.mail.sc5.yahoo.com ESMTP<cr><lf>
>> 23:45:07.218: << EHLO aosake.net<cr><lf>
>> 23:45:08.268: >> 250-smtp812.mail.sc5.yahoo.com<cr><lf>
>> 23:45:08.303: >> 250-AUTH LOGIN PLAIN<cr><lf>
>> 23:45:08.334: >> 250-PIPELINING<cr><lf>
>> 23:45:08.368: >> 250 8BITMIME<cr><lf>
>> 23:45:08.416: << AUTH LOGIN<cr><lf>
>> 23:45:08.463: >> 334 base64stuff<cr><lf>
>> 23:45:08.495: << base64stuff=<cr><lf>
>> 23:45:08.546: >> 334 base64stuff<cr><lf>
>> 23:45:08.578: << base64stuff==<cr><lf>
>> 23:45:08.686: >> 235 ok, go ahead (#2.0.0)<cr><lf>
>> 23:45:08.718: << MAIL FROM:<..Úser..@pacbell.net><cr><lf>
>> 23:45:08.768: >> 250 ok<cr><lf>
>> 23:45:08.847: << RCPT TO:<..Úser..@msn.com><cr><lf>
>> 23:45:08.899: >> 250 ok<cr><lf>
>> 23:45:08.930: << DATA<cr><lf>
>> 23:45:08.009: >> 354 go ahead<cr><lf>
>> 23:45:09.393: << Received: from Spooler by aosake.net (Mercury/32 v4.01b)
>> ID MO000017;<cr><lf>  26 Dec 2004 23:45:08 -0800<cr><lf> 23:45:09.428: <<
>> Received: from spooler by aosake.net (Mercury/32 v4.01b); 26 Dec 2004
>> 23:44:48 -0800<cr><lf> 23:45:09.464: << Received: from [192.168.102.101]
>> (192.168.102.101) by aosake.net (Mercury/32 v4.01b) with ESMTP ID
>> MG000016;<cr><lf> 23:45:09.496: <<    26 Dec 2004 23:44:38 -0800<cr><lf>
>> 23:45:09.532: << Received: from 127.0.0.1 (AVG SMTP 7.0.298 [265.6.5]);
>> Sun, 26 Dec 2004 23:44:35 -0800<cr><lf> 23:45:09.568: << Message-ID:
>> <000701c4ebe7$e9512b00$6566a8c0@aosake.net><cr><lf> ... Message text ...
>> Message text 23:45:12.189: << <cr><lf> 23:45:12.223: << .<cr><lf>
>> 23:45:13.313: >> 250 ok 1104133514 qp 47446<cr><lf>
>> 23:45:13.351: << QUIT<cr><lf>
>> 23:45:13.398: >> 221 smtp812.mail.sc5.yahoo.com<cr><lf>
>> 23:45:13.433: --- Connection closed normally at Sun Dec 26 23:45:13 2004.
>> --- 23:45:13.468:
>
> The message logged above has not, yet anyway, been returned. If you are
> confused by all of the domains, well, that is the way that SMTP was 
> designed
> to work. The key parts to know are that "smtp812.mail.sc5.yahoo.com" will
> only relay if the AUTH LOGIN lines, there are two, are matched with an
> authorized user. "smtp812.mail.sc5.yahoo.com" would have refused the
> connection if either of the AUTH LOGIN lines were incorrect. Domain names
> and IP addresses are irrelevant in this case; SBC Yahoo! knows whom to
> contact if the message violates the AUP/TOS in any way.
>
>> Mercuy Mail core log:
>> I 20041226 1434 MG000030 MAILER-DAEMON@yahoo.com        Lorrie
>> 5697
>
> This merely logs the Yahoo! mailer returning the rejected message. What I
> did not include from the Yahoo! bounce are the headers of the included,
> bounced message:
>
>> --- Original message follows.
>>
>> Return-Path: <..Úser..@pacbell.net>
>> Received: from unknown (HELO aosake.net)
>>   (..Úser..%pacbell.net@66.125.88.247 with login) by
>> smtp800.mail.sc5.yahoo.com with SMTP; 26 Dec 2004 22:34:22 -0000
>> Received: from Spooler by aosake.net (Mercury/32 v4.01b) ID MO00002F;
>>   26 Dec 2004 14:34:15 -0800
>> Received: from spooler by aosake.net (Mercury/32 v4.01b); 26 Dec 2004
>> 14:33:49 -0800
>> Received: from [192.168.102.101] (192.168.102.101) by aosake.net
>>    (Mercury/32 v4.01b) with ESMTP ID MG00002E; 26 Dec 2004 14:33:48 -0800
>> Received: from 127.0.0.1 (AVG SMTP 7.0.298 [265.6.5]); Sun, 26 Dec 2004
>> 14:33:54 -0800
>> Message-ID: <000a01c4eb9a$fb64e180$6566a8c0@aosake.net>
>> From: "Úser Ñame" <..Úser..@pacbell.net>
>> To: "Úser Ñame" <..Úser..@msn.com>
>> References: <BAY11-DAV55AED8D033E4135F0C1BDAD2A70@phx.gbl>
>> Subject: Re: Fw: One more Christmas Card
>> Date: Sun, 26 Dec 2004 14:33:54 -0800
>> MIME-Version: 1.0
>> Content-Type: multipart/alternative;
>> boundary="----=_NextPart_000_0007_01C4EB57.ED27B0E0"
>> X-Priority: 3
>> X-MSMail-Priority: Normal
>> X-Mailer: Microsoft Outlook Express 6.00.2800.1478
>> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
>> X-AC-Weight: [####] (Whitelisted) -9999
>> X-CC-Diagnostic:
>
> Now, what part of the above message headers suggests that the error 
> message:
>
>> Message from  yahoo.com.
>> Unable to deliver message to the following address(es).
>>
>> <..Úser..@msn.com>:
>> 65.54.190.7 does not like recipient.
>> Remote host said: 550 5.7.1 Unable to relay for ..Úser..@msn.com
>> Giving up on 65.54.190.7.
>
> Is accurately reporting a relay attempt? It looks to me like
> "mc2.bay6.hotmail.com" is either FUBAR, or deliberately blocking an SBC
> Yahoo! MTA!
>
>> 12/26/04 23:39:34 dns 65.54.190.7
>> nslookup 65.54.190.7
>> Canonical name: mc2.bay6.hotmail.com
>> Addresses:
>>   65.54.190.7
>
> Sometimes a mystery problem is just that; a mystery. There is no solution
> that I can think of here. The sender tried again, and the retry has not 
> been
> returned. The total lapsed time for the rejected message to bounce is 
> under
> one minute:
>
>> O 20041226 1433 MG00002E ..Úser..@pacbell.net           ..Úser..@msn.com
>> I 20041226 1434 MG000030 MAILER-DAEMON@yahoo.com        Local Úser
>
>
> The retry went out:
>
>> O 20041226 2344 MG000016 ..Úser..@pacbell.net           ..Úser..@msn.com
>> I 20041226 2358 MG000018 admin@[67.112.26.182]          FILTER:F:\Email
>> Stores\M-Mail\ 1380
>
> There is no later inbound entry than the one from a friend's router, 
> sending
> me the router log.
>
> All this is to show that a "550 5.7.1 Unable to relay for 
> ..Úser..@msn.com"
> error message may not accurately describe the problem encountered.

Relevant Pages

  • Re: Question Re Securing SMTP Server
    ... I don't care at all about the Sender or Reply To information. ... using my SMTP server as a relay for their nefarious purposes. ... client and enter this into our SMTP server security configuration. ...
    (microsoft.public.inetserver.iis.smtp_nntp)
  • Re: More questins on SMTP spam attacks.
    ... If a session is not allowed to relay to a domain -- because it is not ... A user comes into my SMTP server, ... The SMTP server accepts the emails, ...
    (microsoft.public.inetserver.iis.smtp_nntp)
  • Re: Windows 2003 smtp relay settings for quoted string and percent hac
    ... a registered user, as this will actually send mail. ... the destination smtp address is a remote address. ... Once you do this, you should see that the relay attempts, while they may ... I have the smtp server setup to not allow ...
    (microsoft.public.exchange.admin)
  • Error sending emails
    ... It looks like you are trying to relay your outbound mail ... Yahoo is not designed to be a server mail relay. ... Go to your SMTP config and remove the "smarthost" ... >There was a SMTP communication problem with the ...
    (microsoft.public.exchange.connectivity)
  • Re: Email problems
    ... this sort of error almost always happens due to the Relay ... configuration of the SMTP Server that CDO is sending the message to. ... Another possible issue involves the Authentication configuration of the SMTP ...
    (microsoft.public.frontpage.programming)