how to resolve 550 5.7.1 Access denied

when sending emails to different people i continue to get the
following error message, among others. I have come to the conclusion
that their mail servers see my email as some type of spam, whether it
be from the IP address of my companies mail server, or the fact that
the email has to go to Taiwan than back to the US and the remote mail
server of the recipient is blocking the email due to where it is
coming from, recognizing the email as spam or it just doesnt like the
IP address of the ISP. I am desperate to find a resolution to this
that doesnt require the MIS in Taiwan to have to do anything on their
side and whatever needs to be done can be dont on my side, or through
my email. We use outlook 2003 for email

These are some of the returns we get when sending emails:

550 5.7.1 Access denied

Another one i get is the following: (email address has been changed as
has the IP address, but the IP address listed in the web address is
the web mail server address)

RCPT To:
<<< 553 Attack detected.


here is another error message our company receives when sending
emails:

550 5.7.1 Mail from xx.xxx.xxx.xxx refused blackholes blacklisted. The
IP address you are using is blacklisted. You should contact your
Internet Service Provider. Go to http://www.icu.net/nospam.html for
more information

Again i have changed the mail server IP address to protect the morons
who administer the email server in this company.

more information about this situation, the email server is located in
taiwan, the office that has all these issues is located in USA. It is
a POP3 email service

i realize that these are 3 different messages, but can anyone please
tell me what i can do to resolve this so emails go through without
being flagged by a remote server.

Am in desperate need of help, need answers ASAP

Thank you in advance, your help is greatly appreciated

Re: how to resolve 550 5.7.1 Access denied

In article
<469652cf-da19-4a4a-92f7-daee239d8cd9@s50g2000hsb.googlegroups.com>,
Jason wrote:

> when sending emails to different people i continue to get the
> following error message, among others. I have come to the conclusion
> that their mail servers see my email as some type of spam, whether it
> be from the IP address of my companies mail server, or the fact that
> the email has to go to Taiwan than back to the US and the remote mail
> server of the recipient is blocking the email due to where it is
> coming from, recognizing the email as spam or it just doesnt like the
> IP address of the ISP. I am desperate to find a resolution to this
> that doesnt require the MIS in Taiwan to have to do anything on their
> side and whatever needs to be done can be dont on my side, or through
> my email. We use outlook 2003 for email

Nowhere in that is there any mention of Sendmail, and if your mail
server *is* Sendmail but is sitting in Taiwan run by people you are
afraid to talk to, there's nothing really relevant to this newsgroup.
Why did you post this question here?

> These are some of the returns we get when sending emails:
>
> 550 5.7.1 Access denied

That is a well-defined (although not directly useful) response code. The
'550' is part of the basic standard for SMTP (originally RFC821, updated
by RFC2821) and is defined in RFC2821 as:

550 Requested action not taken: mailbox unavailable
(e.g., mailbox not found, no access, or command
rejected for policy reasons)

The additional code "5.7.1" is part of an extension of the response code
system (RFC1893 and RFC2034) that provides more precise detail. The
three digits each carry meaning, and the whole picture is provided by
these three pieces of RFC1893:

5.X.X Permanent Failure

A permanent failure is one which is not likely to be
resolved by resending the message in the current form.
Some change to the message or the destination must be
made for successful delivery

X.7.X Security or Policy Status

The security or policy status codes report failures
involving policies such as per-recipient or per-host
filtering and cryptographic operations. Security and
policy status issues are assumed to be under the control
of either or both the sender and recipient.


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.

In short: the receiving server that refuses to accept a message with
this response is telling you that it is doing so because of an
unspecified policy, which *could* be just about anything imaginable.
Policy is subject to the whims of individual mail system operators...


> Another one i get is the following: (email address has been changed as
> has the IP address, but the IP address listed in the web address is
> the web mail server address)
>
> RCPT To:
> <<< 553 Attack detected.
>

Your decision to hide information eliminates any hope of anyone else
trying to help you with this, but your best way of finding out more
about this seems like it should be crystal clear to you from seeing the
undamaged message. The '553' response


> here is another error message our company receives when sending
> emails:
>
> 550 5.7.1 Mail from xx.xxx.xxx.xxx refused blackholes blacklisted. The
> IP address you are using is blacklisted. You should contact your
> Internet Service Provider. Go to http://www.icu.net/nospam.html for
> more information

Again, this message points you to the answer: that web page says that
they use a DNSBL which lists all Taiwan address space. You may want to
contact your correspondents in that domain by some other means and
explain that their ISP has chosen to restrict their service in that
manner. Note that such a severe choice is not really unreasonable for a
US consumer ISP or other business. For many mail systems in the US, the
ratio of bad to good mail offered by machines in Taiwan is in the range
of millions to one or even technically incalculable (divide by zero....
)

> Again i have changed the mail server IP address to protect the morons
> who administer the email server in this company.

That is not an overly strong word.
The most moronic aspect would be the practice of routing all mail from a
US office for outbound transit via Taiwan.

> more information about this situation, the email server is located in
> taiwan, the office that has all these issues is located in USA. It is
> a POP3 email service

POP3 is for retrieving delivered mail from a mail server to a mail
client, or in some cases to a secondary delivery system.

> i realize that these are 3 different messages, but can anyone please
> tell me what i can do to resolve this so emails go through without
> being flagged by a remote server.

Short of addressing the root cause: talk to the people running the
servers that are sending those rejection responses or get their users
who you are trying to mail to do so. Assuming that you are not spamming
and your Taiwan mail system is not itself sending spam, there's a fairly
reasonable chance that you could get that mail system exempted.

Fixing the root cause probably requires you to set up a local mail
system in the US for getting your mail out.

--
Now where did I hide that website...

Re: how to resolve 550 5.7.1 Access denied

In news:bill-F5B27F.14353918042008@news.det.sbcglobal.net,
Bill Cole typed:

> Nowhere in that is there any mention of Sendmail, and if your mail
> server *is* Sendmail ...

The name of the program is sendmail, not Sendmail.

Re: how to resolve 550 5.7.1 Access denied

"Bill Cole" wrote in message
news:bill-F5B27F.14353918042008@news.det.sbcglobal.net...
> In article
> <469652cf-da19-4a4a-92f7-daee239d8cd9@s50g2000hsb.googlegroups.com>,
> Jason wrote:
> > 550 5.7.1 Access denied

Not very helpful as to the reason, but a denial based on local policy. The
other reply's analysis was a bit long winded in its explanation.

The problem is that your IP is probably on one or more DNSBLs and/or has a
generic reverse instead of a real host name. If you are a home ISP
customer, you should be using your ISP's outbound mail server and do not try
to send mail directly.

> > RCPT To:
> > <<< 553 Attack detected.
> >

The URL was helpful, but the rejection message is malformed - incorrect
code.

Re: how to resolve 550 5.7.1 Access denied

Post removed (X-No-Archive: yes)

Re: how to resolve 550 5.7.1 Access denied

In article , "h.stroph" wrote:

> In news:bill-F5B27F.14353918042008@news.det.sbcglobal.net,
> Bill Cole typed:
>
> > Nowhere in that is there any mention of Sendmail, and if your mail
> > server *is* Sendmail ...
>
> The name of the program is sendmail, not Sendmail.

Pedant :)

There are 3 reasons I use the perverse capitalization:

1. I have surrendered to the mystification of people (like, I suspect,
the poster I was responding to) who are confused by the Unix tradition
of non-capitalization and particularly by the use of uncapitalized words
as proper nouns.

2. These days, /usr/{sbin,lib,bin,libexec}/sendmail is fairly likely to
not be Real Sendmail or even an MTA at all. A capitalized Sendmail
clearly does not refer to some sendmail binary put in place as part of
Postfix or an OS/distro maintainer's sendmail script that selects one of
many different sendmail's depending on some config setting.

3. A capitalized Sendmail clearly does not refer narrowly to the
sendmail binary. It lessens the possible misreading of a statement like
"mail.local is part of sendmail."

--
Now where did I hide that website...