Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Relaying Not Allowed - We're NOT Relaying

22 views
Skip to first unread message

Cygnus

unread,
Apr 7, 2006, 4:19:53 PM4/7/06
to
I have seen a lot of discussion about this subject but nothing that I
have tried has helped. Perhaps someone else is equally stumped.

SOMETIMES (important to note, I think), an e-mail sent from our server
to an e-mail address will be rejected with the following message:

Your message did not reach some or all of the intended recipients.

Subject: Shubin Humor
Sent: 4/4/2006 1:49 PM

The following recipient(s) could not be reached:

x...@xxxxxxx.com on 4/4/2006 1:50 PM
You do not have permission to send to this recipient. For
assistance, contact your system administrator.
<FIRSTBOOKSDC.firstbooks.local #5.7.1 smtp;550 5.7.1 Unable to relay
for x...@xxxxxxx.com>

And SOMETIMES we get a similar but different error:

Your message did not reach some or all of the intended recipients.

Subject: RE: Turks and Kurds
Sent: 4/6/2006 9:53 AM

The following recipient(s) could not be reached:

xxx...@bxxxxxxxxxxxx.com on 4/6/2006 9:53 AM
There was a SMTP communication problem with the recipient's
email server. Please contact your system administrator.
<FIRSTBOOKSDC.firstbooks.local #5.5.0 smtp;554
<xxx...@xxxxxxxxxx.com>: Relay access denied>

I admit to being a relative lightweight when it comes to server
management and have been stumped in trying to figure out the solution.

Anyone? Bueller?

Susan

unread,
Apr 7, 2006, 4:45:12 PM4/7/06
to
do you mean emails to external addresses? does it happen with the same
addresses/domains all the time? Depends where the emails are originating
(and the originating address) and where they're bound what the problem could
be...

--
Susan Conkey [MVP]

"Cygnus" <s...@firstbooks.com> wrote in message
news:1144441193.5...@u72g2000cwu.googlegroups.com...

Cygnus

unread,
Apr 7, 2006, 5:14:16 PM4/7/06
to
External addresses, yes. The problem is intermittent. My response to
people who have experienced it here has been "try it again" and the
messages usually go through.

Should FIRSTBOOKSDC.firstbooks.local be showing up in this error or
should our domain name be there?

I have thought that this was being bounced because of a reverse lookup
that failed but I cannot say specifically that that is the issue.

Help?

Cygnus

unread,
Apr 7, 2006, 5:21:22 PM4/7/06
to
In thinking about this some more, I wonder if another error that we are
getting is related...

I have set up monitoring and reporting e-mails to be sent to me on a
daily/emergency basis. I get the original "you are going to get these
messages" e-mail message that confirms that I set up the reporting
properly... but I never get any monitoring e-mails. I checked the
Performance Report and there is a critical application error which
reads:

An error occurred in attempting to send a Server Status Report in
e-mail. The e-mail message was not sent. There may be a problem with
connectivity or system configuration. Ensure that the ASP.NET State
Service and IIS Admin service are running. You can also try resetting
your monitoring and reporting preferences. To do this, open the
Monitoring and Reporting taskpad in Server Management, and then click
Set Up Monitoring Reports and Alerts.

The event ID is 4353.

Any chance that there could be some relation between these two problems?

Susan

unread,
Apr 7, 2006, 5:26:50 PM4/7/06
to
From this article (http://www.faqs.org/rfcs/rfc1893.html)

X.7.1 Delivery not authorized, message refused

The sender is not authorized to send to the destination.
This can be the result of per-host or per-recipient
filtering. This memo does not discuss the merits of any
such filtering, but provides a mechanism to report such.
This is useful only as a permanent error.

So it does not actually mean that the server you are sending to thinks you
are relaying...this could be a transient thing, or possibly based even on
some content filtering software...do you host your own Internet email? When
the user sends again, do they send exactly the same message again, and it
gets through?

--
Susan Conkey [MVP]

"Cygnus" <s...@firstbooks.com> wrote in message
news:1144441193.5...@u72g2000cwu.googlegroups.com...

Susan

unread,
Apr 7, 2006, 5:28:02 PM4/7/06
to
i don't really think this is related to the Internet email issue...

--
Susan Conkey [MVP]

"Cygnus" <s...@firstbooks.com> wrote in message

news:1144444882.2...@e56g2000cwe.googlegroups.com...

Cygnus

unread,
Apr 7, 2006, 5:54:53 PM4/7/06
to
>do you host your own Internet email?

No. Our POP is hosted by our web host. Our SMTP is hosted by our ISP.
Both swear that they are not part of the problem and that this is
happening internally.

>When the user sends again, do they send exactly the same message again, and it gets through?

I have asked this question but the users affected cannot verify. I am
having them do this the very next time that this is an issue.

I did just find something and perhaps THAT is the problem.
Under properties for our default virtual SMTP server, under tab Access,
Relay - our internal IP was not listed, just 127.0.0.1 was there. I
added our internal firewall IP. Will this do the trick, ya think?

Susan

unread,
Apr 7, 2006, 6:08:19 PM4/7/06
to
I don't believe that should be necessary, but depending on your set up, it
might be a possible issue...

--
Susan Conkey [MVP]

"Cygnus" <s...@firstbooks.com> wrote in message

news:1144446892....@j33g2000cwa.googlegroups.com...

Cygnus

unread,
Apr 7, 2006, 6:27:22 PM4/7/06
to
> When the user sends again, do they send exactly the same message again, and it gets through?

Let's play this out. Let's say that the message does get through on a
second send - what would you investigate? Let's say that the repeated
message doesn't get through - what would you investigate?

We do use GFI to filter our incoming mail but it doesn't touch our
outgoing mail so I haven't even looked there. Is it possible that it
actually IS touching our outgoing mail? I'll check...

Susan

unread,
Apr 7, 2006, 6:45:39 PM4/7/06
to
if the exact same message gets through on a second try, that would be really
hard to trouble-shoot...but if the same message with the same subject line,
sent from the same mailbox/address to the same address gets rejected
persistently, it would probably have to do with content filtering (my
guess). If a second, different message gets through (same sending/receiving
addresses), that would give weight to my suspicion. If these are business
emails, you might possibly want to try to contact the receiving domains to
see if you could get on some kind of a "whitelist" to see it that resolves
the issue. We have things like this get blocked at our gateways all the
time, for content. When I find myself having to research too often why an
email doesn't get delivered to one of my users, I whitelist that address so
it is no longer subject to the policy that's stopping it...
--
Susan Conkey [MVP]

"Cygnus" <s...@firstbooks.com> wrote in message

news:1144448841.9...@v46g2000cwv.googlegroups.com...

Cygnus

unread,
Apr 7, 2006, 6:50:32 PM4/7/06
to
Thank you, Susan. I will respond to this thread if/when this issue
rears its ugly head, again.

Rich Matheisen [MVP]

unread,
Apr 7, 2006, 10:32:59 PM4/7/06
to
"Cygnus" <s...@firstbooks.com> wrote:

>>do you host your own Internet email?
>
>No. Our POP is hosted by our web host. Our SMTP is hosted by our ISP.
>Both swear that they are not part of the problem and that this is
>happening internally.

That's easy enough to verify by examinng the SMTP protocol logs.

It's important to know that the error you're seeing could be raised by
any of the servers along the way from your server to the target
server.

Any one of the SMTP servers can look at the RCPT TO address and decide
that, for whatever reason, the domain in the SMTP address isn't one of
theirs and that you aren't permitted to use their machine to send the
message to the target domain.

If you forward all your mail to the ISP for delivery, and you see in
your log files that the RCPT TO (or DATA) command receives the status
you note in your previous postings, then the ISP should be able to
find that transaction in their logs. If they accepted the message and
sent it to the next hop they'll also have a record of that. If they
successfully delivered the message to the hext hop server then your
ISP is absolved of any blame.

>>When the user sends again, do they send exactly the same message again, and it gets through?
>
>I have asked this question but the users affected cannot verify. I am
>having them do this the very next time that this is an issue.
>
>I did just find something and perhaps THAT is the problem.
>Under properties for our default virtual SMTP server, under tab Access,
>Relay - our internal IP was not listed, just 127.0.0.1 was there. I
>added our internal firewall IP. Will this do the trick, ya think?

Nope. That just controls what IP addresses will be allowed to use your
server as a relay.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:h.p...@getronics.com
Or to these, either: mailto:h.p...@pinkroccade.com mailto:melvin.mcp...@getronics.com mailto:melvin.mcp...@pinkroccade.com

Cygnus

unread,
Apr 10, 2006, 12:38:38 PM4/10/06
to
>That's easy enough to verify by examinng the SMTP protocol logs.

Indeed. I don't know why but the last guy who sat in this chair had the
system set up to not retain SMTP protocol logs. I have enabled them and
will look at them this afternoon to see what is happening.

I ran SmtpDiag from Microsoft just now and didn't like the results. I
am wondering if this will help me to get to the root of the problem.
When it got time to look at the Remote and Local Domain Records, both
returned an error of: "The TCP DNS query returned no results."

That sounds like a problem to me. Is it?

Thank you for jumping in, Rich. I am still at a loss here...

Rich Matheisen [MVP]

unread,
Apr 10, 2006, 8:41:48 PM4/10/06
to
"Cygnus" <s...@firstbooks.com> wrote:

Depends . . . do they also use UDP to query DNS? I don't think that
TCP is what most DNS's expect.

>Thank you for jumping in, Rich. I am still at a loss here...

Well, yeah . . . but the log files will at least get you on the side
of the fence where the problem lies. Sometimes problems just need to
be pared down to a smaller scope before they become understandable.
The Internet's a big place and you can't be responsible for the
correct operation of all of it. :)

Cygnus

unread,
Apr 11, 2006, 12:09:47 PM4/11/06
to
So I am looking at these log files and I am probably more confused than
when I hadn't. Why the need to have event codes when those event codes
are not defined anywhere? I have a 4866 and a 3833 but I have no clue
as to what those mean. Why not just do a pass/fail or a go/nogo for
events?

Not only do I not know which side of the fence the problem lies, I am
not sure where the fence is!

Is there an easy - and free - log analyzer that I could download that
would make heads or tails of the log file?

Cygnus

unread,
Apr 11, 2006, 2:50:03 PM4/11/06
to
OK... I did SmtpDiag again and looked at the results for UDP.

Here is what I ran: SmtpDiag jer...@firstbooks.com s...@firstbooks.com
-d 207.176.137.142

Checking local domain records:
Checking MX records using TCP: firstbooks.com
Warning T
Checking MX records using UDP: firstbooks.com
Warning: No MX or A records were found for the local domain. If the
records are not configured, incoming mail can fail to be delievered to
this server.

Checking remote domain records:
Checking MX records using TCP: firstbooks.com
Warning: The TCP DNS query returned no results.
Checking MX recordes using UDP: firstbooks.com
Error: No MX or A records were found for the remote domain. Verify that
the remote domain is valid. Your firewall allows outbound queries
(Windows NT/2000 Server requires TCP), and your DN server can resolve
external domains.

Going to dnsstuff.com and looking up the MX record for firstbooks.com,
I get our host info.

Say... have I mentioned how confused I am?
-Sam

Rich Matheisen [MVP]

unread,
Apr 11, 2006, 8:18:30 PM4/11/06
to
"Cygnus" <s...@firstbooks.com> wrote:

>So I am looking at these log files and I am probably more confused than
>when I hadn't. Why the need to have event codes when those event codes
>are not defined anywhere? I have a 4866 and a 3833 but I have no clue
>as to what those mean. Why not just do a pass/fail or a go/nogo for
>events?

I don't think you're looking at the protocol logs. The protocol logs
are text files with names like ex060411.log, and they're in the
WINDOWS\system32\logfiles\smtpsvc1 directory

The 1st couple of lines in th file look something like this:

#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2006-01-01 05:01:41
#Fields: date time c-ip cs-username s-sitename s-computername s-ip
s-port cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status
sc-bytes cs-bytes time-taken cs-version cs-host cs(User-Agent)
cs(Cookie) cs(Referer)


You'll see lines that look like this (the "250" is the status code
associated with the MAIL FROM command):
2006-01-02 03:26:07 192.168.1.2 AAAAA.ZZZZ.XXX SMTPSVC1 SRVR002
192.168.1.21 0 MAIL - +FROM:<tavri...@inbox.ru> 250 0 45 42 469
SMTP - - - -

>Not only do I not know which side of the fence the problem lies, I am
>not sure where the fence is!
>
>Is there an easy - and free - log analyzer that I could download that
>would make heads or tails of the log file?

Rich Matheisen [MVP]

unread,
Apr 11, 2006, 8:26:49 PM4/11/06
to
"Cygnus" <s...@firstbooks.com> wrote:

>OK... I did SmtpDiag again and looked at the results for UDP.

An here's what the outside world sees:
http://dnsreport.com/tools/dnsreport.ch?domain=firstbooks.com


When I use the DNS Server you tried using here's what I see:

> server 207.176.137.142
Default Server: ns57.zabco.net
Address: 207.176.137.142

> set q=soa
> firstbooks.com
Server: ns57.zabco.net
Address: 207.176.137.142

*** ns57.zabco.net can't find firstbooks.com: No response from server


So, I'd say that DNS server's busted. Use another one that works. Call
the ISP and complain or ask them for the IP address s a working server
(like the one below):

> server ns1.zabco.net.
Default Server: ns1.zabco.net
Addresses: 207.176.137.2, 207.176.137.2

> set q=soa
> firstbooks.com
Server: ns1.zabco.net
Addresses: 207.176.137.2, 207.176.137.2

firstbooks.com
primary name server = ns1.zabco.net
responsible mail addr = root.ns1.zabco.net
serial = 2006040317
refresh = 10800 (3 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 1800 (30 mins)
firstbooks.com nameserver = ns1.zabco.net
firstbooks.com nameserver = ns2.zabco.net
ns1.zabco.net internet address = 207.176.137.2
ns2.zabco.net internet address = 207.176.148.2


Now, getting back to the REAL problem, which has nothing to do with
DNS, who's generating the 554 error?

0 new messages