unable to send email Exch2003

B

Bazzar

I have a client with SBS2003 and Exchnage 2003. It is setup with MX record.

Once before and now this has happened. They can receive emails but not send

to external recipients.

The error is

You do not have permission to send to this recipient. For assistance,

contact your system administrator.

<company.com #5.7.1 smtp;550 5.7.1 <person@external.com>...

Relaying denied. Proper authentication required.
I noticed that the DNS for the MX record points to the company.com and not

the server.name.local which is used in the SMTP - properties - delivery -

advanced - FQDN. It has worked this way for ages apart from these two

episodes. I believe restarting the server last time got it going again but I

want to resolve this now. There is a smart host setup to the correct ISP.

Right now I will ask them to let me restart the server and see if this fixes

it for now. I believe they did try setting the SMTP FQDN to the

server.name.local but it had problems. I don't know what though.

Relaying is restricted to the server, the hardware Firewall is OK.

Any thoughts on this problem and settings? I haven't found any info yet on

this.
 
L

Lanwench [MVP - Exchange]

Bazzar <Bazzar> wrote:
> I have a client with SBS2003 and Exchnage 2003. It is setup with MX
> record.


OK - MX records have to do with your *receiving* mail, not sending it.

Once before and now this has happened. They can receive
> emails but not send to external recipients.

> The error is
> You do not have permission to send to this recipient. For assistance,
> contact your system administrator.
> <company.com #5.7.1 smtp;550 5.7.1 <person@external.com>...
> Relaying denied. Proper authentication required.>


Yes - the SMTP server you're trying to relay though need authentication in

order for you to use it.

> I noticed that the DNS for the MX record points to the company.com
> and not the server.name.local which is used in the SMTP - properties
> - delivery - advanced - FQDN. It has worked this way for ages apart
> from these two episodes. I believe restarting the server last time
> got it going again but I want to resolve this now. There is a smart
> host setup to the correct ISP.


The issue is with the smarthost. You have to authenticate to that server. Do

this in the properties of the SBS-created SMTP connector in Exchange System

Manager. Advanced / outbound security.

> Right now I will ask them to let me restart the server and see if
> this fixes it for now. I believe they did try setting the SMTP FQDN
> to the server.name.local


Who are "they" ? If this is a (non-technical) client, don't let them log

into the server at all. I know, that's OT.


> but it had problems. I don't know what
> though.


If you're going to change that to anything, make sure it *isn't* the

private/local FQDN. It won't make any difference anyway as you're sending

through a smarthost.

If you're going to change it from the default, might as well make it match

your public FQDN - as in,. mail.mydomain.com.



> Relaying is restricted to the server, the hardware Firewall is OK.


Cool, but this has nothing to do with your own relay or firewall, tho.

> Any thoughts on this problem and settings? I haven't found any info
> yet on this.


Do you have to use a smarthost? It's generally wise not to if you can avoid

it. Do you have a static public IP with a reverse-lookup (the ISP has to set

that up)?
 
B

Bazzar

Hi thanks and I will heed your advice about cross posting.

I have since run SMTPDiag and it was fine on all points.

I had just changed permissions and demoted them all to Users to stop

meddling as a Mac user thought he knew things and proved to be dangerous.

Taken care of now.

I did change the FQDN to the mydomain.com form and it made no difference. I

will get back on later when I have some time, its bed time for me now and I'm

stuffed!

Funny thing is, this has worked fine up to now. Since it failed I had a look

at the settings and reported what I found. Yeah, I know the firewall etc was

not really it but I find sometimes if I don't mention stuff it gets asked. As

for the smart host I will look at the fixed IP as they do have it and I'll

check the revlookup. Been a long day on several fronts. Why is it not wise to

use a smart host? Can you expand a little on that for me? Would the setup I

explained be capable of running then fail after months or would something

trigger it?

your input is really appreciated

Barry

"Lanwench [MVP - Exchange]" wrote:


> Bazzar <Bazzar> wrote:
> > I have a client with SBS2003 and Exchnage 2003. It is setup with MX
> > record.


> OK - MX records have to do with your *receiving* mail, not sending it.

> Once before and now this has happened. They can receive
> > emails but not send to external recipients.
> > The error is
> > You do not have permission to send to this recipient. For assistance,
> > contact your system administrator.
> > <company.com #5.7.1 smtp;550 5.7.1 <person@external.com>...
> > Relaying denied. Proper authentication required.>


> Yes - the SMTP server you're trying to relay though need authentication in
> order for you to use it.
> > I noticed that the DNS for the MX record points to the company.com
> > and not the server.name.local which is used in the SMTP - properties
> > - delivery - advanced - FQDN. It has worked this way for ages apart
> > from these two episodes. I believe restarting the server last time
> > got it going again but I want to resolve this now. There is a smart
> > host setup to the correct ISP.


> The issue is with the smarthost. You have to authenticate to that server. Do
> this in the properties of the SBS-created SMTP connector in Exchange System
> Manager. Advanced / outbound security.
> > Right now I will ask them to let me restart the server and see if
> > this fixes it for now. I believe they did try setting the SMTP FQDN
> > to the server.name.local


> Who are "they" ? If this is a (non-technical) client, don't let them log
> into the server at all. I know, that's OT.
>
> > but it had problems. I don't know what
> > though.


> If you're going to change that to anything, make sure it *isn't* the
> private/local FQDN. It won't make any difference anyway as you're sending
> through a smarthost.

> If you're going to change it from the default, might as well make it match
> your public FQDN - as in,. mail.mydomain.com.
>
> > Relaying is restricted to the server, the hardware Firewall is OK.


> Cool, but this has nothing to do with your own relay or firewall, tho.
> > Any thoughts on this problem and settings? I haven't found any info
> > yet on this.


> Do you have to use a smarthost? It's generally wise not to if you can avoid
> it. Do you have a static public IP with a reverse-lookup (the ISP has to set
> that up)?

>
 
L

Lanwench [MVP - Exchange]

Bazzar <Bazzar> wrote:
> Hi thanks and I will heed your advice about cross posting.

> I have since run SMTPDiag and it was fine on all points.
> I had just changed permissions and demoted them all to Users to stop
> meddling as a Mac user thought he knew things and proved to be
> dangerous. Taken care of now.


Change the domain admin credentials to make sure nobody can log in at the

server. Users really shouldn't even have local admin rights on their

computers.

> I did change the FQDN to the mydomain.com form and it made no
> difference. I will get back on later when I have some time, its bed
> time for me now and I'm stuffed!

> Funny thing is, this has worked fine up to now. Since it failed I had
> a look at the settings and reported what I found. Yeah, I know the
> firewall etc was not really it but I find sometimes if I don't
> mention stuff it gets asked.


Sure, that's always good.


> As for the smart host I will look at the
> fixed IP as they do have it and I'll check the revlookup. Been a long
> day on several fronts. Why is it not wise to use a smart host? Can
> you expand a little on that for me? Would the setup I explained be
> capable of running then fail after months or would something trigger
> it?


No idea; the ISP controls their server. The reason you want to avoid using a

smarthost is that it removes mail transfer to someone else, beyond your

control - your outbound mail can't be tracked beyond it getting accepted for

relay by the smarthost. If they're slow, if they're blacklisted, etc., you

can't see what's going on directly. Message tracking is a great feature but

is limited in what it can provide if you've got

> your input is really appreciated
> Barry

> "Lanwench [MVP - Exchange]" wrote:
>
> > Bazzar <Bazzar> wrote:
> >> I have a client with SBS2003 and Exchnage 2003. It is setup with MX
> >> record.

>

>> OK - MX records have to do with your *receiving* mail, not sending
> > it.
>

>> Once before and now this has happened. They can receive
> >> emails but not send to external recipients.
> >
>>> The error is
> >> You do not have permission to send to this recipient. For
> >> assistance, contact your system administrator.
> >> <company.com #5.7.1 smtp;550 5.7.1
> >> <person@external.com>... Relaying denied. Proper authentication
> >> required.>

>

>> Yes - the SMTP server you're trying to relay though need
> > authentication in order for you to use it.
> >
>>> I noticed that the DNS for the MX record points to the company.com
> >> and not the server.name.local which is used in the SMTP - properties
> >> - delivery - advanced - FQDN. It has worked this way for ages apart
> >> from these two episodes. I believe restarting the server last time
> >> got it going again but I want to resolve this now. There is a smart
> >> host setup to the correct ISP.

>

>> The issue is with the smarthost. You have to authenticate to that
> > server. Do this in the properties of the SBS-created SMTP connector
> > in Exchange System Manager. Advanced / outbound security.
> >
>>> Right now I will ask them to let me restart the server and see if
> >> this fixes it for now. I believe they did try setting the SMTP FQDN
> >> to the server.name.local

>

>> Who are "they" ? If this is a (non-technical) client, don't let them
> > log into the server at all. I know, that's OT.
> >
> >> but it had problems. I don't know what
> >> though.

>

>> If you're going to change that to anything, make sure it *isn't* the
> > private/local FQDN. It won't make any difference anyway as you're
> > sending through a smarthost.
>

>> If you're going to change it from the default, might as well make it
> > match your public FQDN - as in,. mail.mydomain.com.
> >
> >
>>> Relaying is restricted to the server, the hardware Firewall is OK.

>

>> Cool, but this has nothing to do with your own relay or firewall,
> > tho.
> >
>>> Any thoughts on this problem and settings? I haven't found any info
> >> yet on this.

>

>> Do you have to use a smarthost? It's generally wise not to if you
> > can avoid it. Do you have a static public IP with a reverse-lookup
> > (the ISP has to set that up)?
 
B

Bazzar

Hi again,

Thanks, I removed the smart host from the SMTP virtual server and overlooked

the

SB SMTP Connector settings. Duh!

Now it works again. I appreciate your help. Lost too much sleep recently so

I'm not all that sharp right now. I'm heading back to bed!!

I think the ISP has made some security chnages and simply not bothered to

tell us, or anyone I guess. It was the only change that made a difference,

that's why I make that guess. They never admit to anything but it is the only

thing I can't check. I've now noticed others who had the same experience.

Again, thank you. I will note this experience for future reference.

"Lanwench [MVP - Exchange]" wrote:


> Bazzar <Bazzar> wrote:
> > Hi thanks and I will heed your advice about cross posting.
> > I have since run SMTPDiag and it was fine on all points.
> > I had just changed permissions and demoted them all to Users to stop
> > meddling as a Mac user thought he knew things and proved to be
> > dangerous. Taken care of now.


> Change the domain admin credentials to make sure nobody can log in at the
> server. Users really shouldn't even have local admin rights on their
> computers.
> > I did change the FQDN to the mydomain.com form and it made no
> > difference. I will get back on later when I have some time, its bed
> > time for me now and I'm stuffed!
> > Funny thing is, this has worked fine up to now. Since it failed I had
> > a look at the settings and reported what I found. Yeah, I know the
> > firewall etc was not really it but I find sometimes if I don't
> > mention stuff it gets asked.


> Sure, that's always good.
>
> > As for the smart host I will look at the
> > fixed IP as they do have it and I'll check the revlookup. Been a long
> > day on several fronts. Why is it not wise to use a smart host? Can
> > you expand a little on that for me? Would the setup I explained be
> > capable of running then fail after months or would something trigger
> > it?


> No idea; the ISP controls their server. The reason you want to avoid using a
> smarthost is that it removes mail transfer to someone else, beyond your
> control - your outbound mail can't be tracked beyond it getting accepted for
> relay by the smarthost. If they're slow, if they're blacklisted, etc., you
> can't see what's going on directly. Message tracking is a great feature but
> is limited in what it can provide if you've got
> > your input is really appreciated
> > Barry
> > "Lanwench [MVP - Exchange]" wrote:
> >
> >> Bazzar <Bazzar> wrote:
> >>> I have a client with SBS2003 and Exchnage 2003. It is setup with MX
> >>> record.
> >
> >> OK - MX records have to do with your *receiving* mail, not sending
> >> it.
> >
> >> Once before and now this has happened. They can receive
> >>> emails but not send to external recipients.
> >>
> >>> The error is
> >>> You do not have permission to send to this recipient. For
> >>> assistance, contact your system administrator.
> >>> <company.com #5.7.1 smtp;550 5.7.1
> >>> <person@external.com>... Relaying denied. Proper authentication
> >>> required.
> >
> >> Yes - the SMTP server you're trying to relay though need
> >> authentication in order for you to use it.
> >>
> >>> I noticed that the DNS for the MX record points to the company.com
> >>> and not the server.name.local which is used in the SMTP - properties
> >>> - delivery - advanced - FQDN. It has worked this way for ages apart
> >>> from these two episodes. I believe restarting the server last time
> >>> got it going again but I want to resolve this now. There is a smart
> >>> host setup to the correct ISP.
> >
> >> The issue is with the smarthost. You have to authenticate to that
> >> server. Do this in the properties of the SBS-created SMTP connector
> >> in Exchange System Manager. Advanced / outbound security.
> >>
> >>> Right now I will ask them to let me restart the server and see if
> >>> this fixes it for now. I believe they did try setting the SMTP FQDN
> >>> to the server.name.local
> >
> >> Who are "they" ? If this is a (non-technical) client, don't let them
> >> log into the server at all. I know, that's OT.
> >
> >>> but it had problems. I don't know what
> >>> though.
> >
> >> If you're going to change that to anything, make sure it *isn't* the
> >> private/local FQDN. It won't make any difference anyway as you're
> >> sending through a smarthost.
> >
> >> If you're going to change it from the default, might as well make it
> >> match your public FQDN - as in,. mail.mydomain.com.
> >
> >>
> >>> Relaying is restricted to the server, the hardware Firewall is OK.
> >
> >> Cool, but this has nothing to do with your own relay or firewall,
> >> tho.
> >>
> >>> Any thoughts on this problem and settings? I haven't found any info
> >>> yet on this.
> >
> >> Do you have to use a smarthost? It's generally wise not to if you
> >> can avoid it. Do you have a static public IP with a reverse-lookup
> >> (the ISP has to set that up)?


>
 
L

Lanwench [MVP - Exchange]

Bazzar <Bazzar> wrote:
> Hi again,

> Thanks, I removed the smart host from the SMTP virtual server and
> overlooked the
> SB SMTP Connector settings. Duh!

> Now it works again. I appreciate your help. Lost too much sleep
> recently so I'm not all that sharp right now. I'm heading back to
> bed!!

> I think the ISP has made some security chnages and simply not
> bothered to tell us, or anyone I guess. It was the only change that
> made a difference, that's why I make that guess. They never admit to
> anything but it is the only thing I can't check. I've now noticed
> others who had the same experience.

> Again, thank you. I will note this experience for future reference.


No problem - glad it's all working now. Get some sleep :)

> "Lanwench [MVP - Exchange]" wrote:
>
> > Bazzar <Bazzar> wrote:
> >> Hi thanks and I will heed your advice about cross posting.
> >
>>> I have since run SMTPDiag and it was fine on all points.
> >> I had just changed permissions and demoted them all to Users to stop
> >> meddling as a Mac user thought he knew things and proved to be
> >> dangerous. Taken care of now.

>

>> Change the domain admin credentials to make sure nobody can log in
> > at the server. Users really shouldn't even have local admin rights
> > on their computers.
> >
>>> I did change the FQDN to the mydomain.com form and it made no
> >> difference. I will get back on later when I have some time, its bed
> >> time for me now and I'm stuffed!
> >
>>> Funny thing is, this has worked fine up to now. Since it failed I
> >> had a look at the settings and reported what I found. Yeah, I know
> >> the firewall etc was not really it but I find sometimes if I don't
> >> mention stuff it gets asked.

>

>> Sure, that's always good.
> >
> >> As for the smart host I will look at the
> >> fixed IP as they do have it and I'll check the revlookup. Been a
> >> long day on several fronts. Why is it not wise to use a smart host?
> >> Can you expand a little on that for me? Would the setup I explained
> >> be capable of running then fail after months or would something
> >> trigger it?

>

>> No idea; the ISP controls their server. The reason you want to avoid
> > using a smarthost is that it removes mail transfer to someone else,
> > beyond your control - your outbound mail can't be tracked beyond it
> > getting accepted for relay by the smarthost. If they're slow, if
> > they're blacklisted, etc., you can't see what's going on directly.
> > Message tracking is a great feature but is limited in what it can
> > provide if you've got
> >
>>> your input is really appreciated
> >> Barry
> >
>>
>>> "Lanwench [MVP - Exchange]" wrote:
> >
>>>> Bazzar <Bazzar> wrote:
> >>>> I have a client with SBS2003 and Exchnage 2003. It is setup with
> >>>> MX record.
> >>
>>>> OK - MX records have to do with your *receiving* mail, not sending
> >>> it.
> >>
>>>> Once before and now this has happened. They can receive
> >>>> emails but not send to external recipients.
> >>>
>>>>> The error is
> >>>> You do not have permission to send to this recipient. For
> >>>> assistance, contact your system administrator.
> >>>> <company.com #5.7.1 smtp;550 5.7.1
> >>>> <person@external.com>... Relaying denied. Proper authentication
> >>>> required.
>>>
>>>> Yes - the SMTP server you're trying to relay though need
> >>> authentication in order for you to use it.
> >>>
>>>>> I noticed that the DNS for the MX record points to the company.com
> >>>> and not the server.name.local which is used in the SMTP -
> >>>> properties - delivery - advanced - FQDN. It has worked this way
> >>>> for ages apart from these two episodes. I believe restarting the
> >>>> server last time got it going again but I want to resolve this
> >>>> now. There is a smart host setup to the correct ISP.
> >>
>>>> The issue is with the smarthost. You have to authenticate to that
> >>> server. Do this in the properties of the SBS-created SMTP connector
> >>> in Exchange System Manager. Advanced / outbound security.
> >>>
>>>>> Right now I will ask them to let me restart the server and see if
> >>>> this fixes it for now. I believe they did try setting the SMTP
> >>>> FQDN to the server.name.local
> >>
>>>> Who are "they" ? If this is a (non-technical) client, don't let
> >>> them log into the server at all. I know, that's OT.
> >>
>>>>> but it had problems. I don't know what
> >>>> though.
> >>
>>>> If you're going to change that to anything, make sure it *isn't*
> >>> the private/local FQDN. It won't make any difference anyway as
> >>> you're sending through a smarthost.
> >>
>>>> If you're going to change it from the default, might as well make
> >>> it match your public FQDN - as in,. mail.mydomain.com.
> >>
>>>>
>>>>> Relaying is restricted to the server, the hardware Firewall is OK.
> >>
>>>> Cool, but this has nothing to do with your own relay or firewall,
> >>> tho.
> >>>
>>>>> Any thoughts on this problem and settings? I haven't found any
> >>>> info yet on this.
> >>
>>>> Do you have to use a smarthost? It's generally wise not to if you
> >>> can avoid it. Do you have a static public IP with a reverse-lookup
> >>> (the ISP has to set that up)?
 

Similar threads

Top