SMTP 553 From: address not verified

[glnbnz]

I am on a network and Exchange Server 2003 is our email client. Some of my
co-workers are getting this message when they are sending email:

Subject: Undeliverable

There was a SMTP communication problem with the recipient's email server.
Please contact your system administrator.
<crii.us #5.5.0 smtp;553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html>

Personally I don't think it is a problem with the Exchange Server here. But
I would like to verify it as more then one employee is getting the same
message. Could anyone help me with this?

Thank you

 

[VanguardLH]

I am on a network and Exchange Server 2003 is our email client. Some
of my
co-workers are getting this message when they are sending email:

Subject: Undeliverable

There was a SMTP communication problem with the recipient's email
server.
Please contact your system administrator.
<crii.us #5.5.0 smtp;553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html>

Personally I don't think it is a problem with the Exchange Server
here. But
I would like to verify it as more then one employee is getting the
same
message. Could anyone help me with this?

Thank you

Are these legitimate (valid) e-mail addresses at the receiving mail
host? Looks like the receiving mail host is telling your sending host
that there is no such account at that destination.

Look at the headers to see in the Received lines as to which mail host
is issued this NDR (non-delivery report) e-mail. If it is the
receiving mail host issuing the NDR, you can't do anything because it
claims there is no such account there.

What is odd is that the NDR claims the *From* address is not valid.
Well, does your nameserver have an MX record for your Exchange server?
Does it have a PTR record for your mail host? Many e-mail services
will reject e-mails sent from mail hosts for which there is no check
at the nameserver for that domain that the sending mail host is
authorized to send e-mail. That is, the receiving mail host queries
the nameserver at the domain for the sending mail host to get back an
MX record. If there is no MX record (or it doesn't specify the same
one as what connected to the receiving mail host) then the receiving
mail host rejects the mail session. It cannot verify that the
domain's nameserver has qualified that the sending mail host on that
domain is authorized to send e-mail from there. For example, a user
might be running their own mail server on their home PC and even have
a static IP address (to get around the spam filter that checks if the
sending mail host is using a dynamic IP address). However, a user on
domain running their own mail server won't have a record of their mail
host in that domain's nameserver; i.e., that ISP's customer is not
authorized to be sending e-mails from that domain. The receiving mail
host does a reverse lookup to check the sending mail host is
authorized to send from its claimed domain.

What this means is that your mail server and nameserver are not
properly configured for sending e-mails from your domain.

Read:
http://www.saas.nsw.edu.au/solutions/dns.html
http://postmaster.info.aol.com/info/rdns.html

 

[RipplesGuy]

I have been having the same issue in Eudora, and elsewhere on the web
discovered several people reporting that YAHOO has made a change in their
SMTP settings so they are CASE-SENSITIVE (or should I say "case sensitive"?).

I stopped having the issue once I changed my "return address" in the
seetings from (e-mail address removed) to (e-mail address removed)

I hope that helps.

-p

 

[Brian Tillman]

I have been having the same issue in Eudora, and elsewhere on the web
discovered several people reporting that YAHOO has made a change in
their SMTP settings so they are CASE-SENSITIVE (or should I say "case
sensitive"?).

I stopped having the issue once I changed my "return address" in the
seetings from (e-mail address removed) to (e-mail address removed)

The RFC for SMTP mail says that the domain cannot be case-sensitive,
although the username portion of an address can be.

 

[Magnolia00]

I have been having the same issue as well. It appears it started sometime
last week. Are you using SBC's email server as a smart host? I am and that
appears to be the issue. What I had to do to get this resolved was follow the
instructions on the Yahoo link given in the NDR email and add my email
account that I am using on my Exchange server. Once added I was sent an email
to my Exchange account from Yahoo asking me to verify that account by
clicking on a link and signing in to my yahoo account. Pretty much, from what
I can see, they are just trying to confirm now that email being routed
through their SMTP server is from an account you have authorized. I think
it's pretty stupid since you already have to use your login to use their SMTP
servers as a smart host.

 

[Art1333]

I've got a 2003 Exchange server that a lot of my users access via my POP3 and
they use their ISP (namely AT&T/SBC) for their SMTP server. It's NOT your
Exchange. They're getting this error as well. Apparently, it looks like
AT&T is tightening their protocols to prevent spoofing emails. If you follow
the link provided, it basically walks someone through authorizing a valid
email address (NOT SBC, AT&T, or Yahoo) to be able to send through AT&T's
SMTP server. I'm not sure about the case sensitivity though.....

 

[N. Miller]

I've got a 2003 Exchange server that a lot of my users access via my POP3 and
they use their ISP (namely AT&T/SBC) for their SMTP server. It's NOT your
Exchange. They're getting this error as well. Apparently, it looks like
AT&T is tightening their protocols to prevent spoofing emails. If you follow
the link provided, it basically walks someone through authorizing a valid
email address (NOT SBC, AT&T, or Yahoo) to be able to send through AT&T's
SMTP server. I'm not sure about the case sensitivity though.....

I am seeing the same problem using Yahoo!'s server ('smtp.att.yahoo.com' is
*not* an AT&T mail host). I get around the problem by using an actual AT&T
mail host ('smpauth.sbcglobal.net').

 

[N. Miller]

I am on a network and Exchange Server 2003 is our email client. Some of my
co-workers are getting this message when they are sending email:

Subject: Undeliverable

There was a SMTP communication problem with the recipient's email server.
Please contact your system administrator.
<crii.us #5.5.0 smtp;553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html>

Personally I don't think it is a problem with the Exchange Server here. But
I would like to verify it as more then one employee is getting the same
message. Could anyone help me with this?

It is a change in the way that Yahoo! authenticates users of their servers.
I am told that you have to have a sender email address matching the domain
of the user name in the server log in.

 

[Brian Tillman]

I am seeing the same problem using Yahoo!'s server
('smtp.att.yahoo.com' is *not* an AT&T mail host). I get around the
problem by using an actual AT&T mail host ('smpauth.sbcglobal.net').

It should be possible with any SMTP service that requires SMTP
authentication. Supply the proper credentials and the server doesn't care
about the sending address.

 

[BJL]

We are having a real time with this whole problem. As noted earlier
there is NO issue with the capitalization as noted by some earlier
posts. We have tested that just to be sure.

It seems that AT&T does not allow a "From" address that is different
that the one used to login into their SMTP mail server.

As noted by other posts, you can try to add the other email to your
verified email list. However, this has not corrected our problem.

This appears to be a change since we have been running with a "From"
address from our old mail service which we still use for inbound
mail. The old mail service does not allow access to their SMTP
servers from the internet and they told us we should be using our
ISP's SMTP server. Which we have for years.

If anyone has a suggestion or who to call at ATT that can help us it
would be apprecited. The folks on the help line really don't
understand the problem and can offer not help other than "your 'from'
address is wrong."

Please help.

 

[Brian Tillman]

We are having a real time with this whole problem. As noted earlier
there is NO issue with the capitalization as noted by some earlier
posts. We have tested that just to be sure.

It seems that AT&T does not allow a "From" address that is different
that the one used to login into their SMTP mail server.

Yes they do. I do it all the time. Besides, the From header is never the
way to specify a different sending address when using POP. The From header
is useful only in an Exchange environment.

If anyone has a suggestion or who to call at ATT that can help us it
would be apprecited. The folks on the help line really don't
understand the problem and can offer not help other than "your 'from'
address is wrong."

Just create an account in Outlook that appears exacly the same as your
original account, but change the "E-mail Address" field to be the sender
address you want the outgoing message to have. Modify the Send/Receive
group to excluse that account when receiving mail. Select that account when
sending the message if you want to change the seding address.

 

[BJL]

Brian, thanks for the help with this.

After lots of testing we have arrived at the answer to our problem.
And some of the information we provided earlier was incorrect.

So to help others who may have this problem here is our solution.

The folks at AT&T (previously SBC for us) have changed the rules about
the "From" field in the SMTP transaction.

So in our case we use "smtp.att.yahoo.com" with port 465 and an
encrypted connection (SSL).

We log on with our AT&T account and password.

As Brian pointed out we have, as the user information, my name and my
email address which is NOT an ATT&T account but an "external email".
Whole different domain name.

Now what happens when you send an email is that we log-in just fine to
the SMTP server, but the "from" address that Outlook (or any mail
program) gives is this "external email" address.

AT&T now looks that name up, and here is the important part, it looks
the "external email" address up in your AT&T mail accounts. NOT your
verified alternative email addresses. You must have this "external
email" address listed as a mail account that you can send email as
from the AT&T/Yahoo web mail interface. So the "verification" must be
done as part of setting up your AT&T mailbox and adding this as an
"account". You don't need to set it up to receive messages from this
email address (click on the "skip this step"). Setting up this
account will go through the "verification" steps and note that email
address is verified.

In addition, the email address that the AT&T/Yahoo mail saves when you
sent up that mail account, is converted to all lower case letters.
And the email address you have as the from address MUST be all lower
case or there is no match.

So the confusion that even the help desk folks seem to have is that a
"verified email address" is not going to get things to work unless you
have it set up in the web based mail. (The folks on the phone kept
having me delete and reestablish my "alternative email" address and
then press the "verify" button. This did nothing to fix the issue)

And if you get over that one and configure the email account in the
web mail. You run into the "letter case" matters.

So for now things are running just great for us. This is, as we
reported earlier, a change since we were working just fine for over
two years and never had to do any of this.

I hope this helps some one else avoid all the time we spent to get
back opeational.

 

[yorkman]

Alright!!! I've had this problem up until a few minutes ago. Your solution
worked for me! The trick was to have the from email address match EXACTLY
what you have in Rogers Yahoo webmail or whatever webmail interface you use.
I had '(e-mail address removed)' in Rogers Yahoo webmail but on Exchange I had
'(e-mail address removed)'

Here's what I changed to fix it:

1) went into Active Directory Users & Computers in Windows 2003
2) on the General tab, I changed the e-mail address from
(e-mail address removed) to (e-mail address removed)
3) on the Exchange E-mail Addresses tab, I changed the SMTP address from
(e-mail address removed) to (e-mail address removed)

I sent four quick messages to various e-mail addresses and they all went
through OK! Hip-hip-hooray to BJL!!

Funny thing is, the thought of doing this at one point did cross my mind but
because we're dealing with Windows here, I never bothered to take it
seriously. If it was Linux, I'd think otherwise. Guess it's better to make
it habit to match the case, regardless of which OS you're dealing with, or
think you're dealing with.