Re: All external email for new users being delivered to administrator

"Graham Macrae" <g.macrae@xxxxxxxxxxx> wrote:


Rich Matheisen [MVP] wrote:
Are you receiving the original message, or are you receiving a
non-delivery report with the original message available when you click
the "Send again" button?

The administrator receives the original message. I've set a rule in
Outlook to forward these to the actual recipient so they receive them
as a forwarded mail. Internal mail works OK.

So the "To:" header has the correct information? That's the only way I
can figure you've been able to construct a rule to do that. What about
the RCPT TO command from the sending SMTP server?

There is no explicit redirection on the user accounts.

It is not all user accounts but does now appear to be all new accounts
that are added.

Are you letting the Recipient Policy assign the e-mail address, or are
you supplying an e-mail address as you create the mailbox? If you put
something into the "E-mail address" of the user before the RUS gets to
the account the RUS won't mailbox-enable the account. You'll have the
impression that the user account has an e-mail address, but no mailbox
will be assigned to the user.

How could I verify this? I did not set up the account so cannot be sure
but the Recipient Policy IS enabled and the email address appears to be
correct.

If that's true then the RCPT To command that Exchange sees isn't
right.

I'm assuming the recipient must have a mailbox as (a) it
appears in the Exchange manager tree and (b) tehy receive internal mail
OK.

"Internal" messages don't use the SMTP address. Outlook gets the
"legacyExchangeDN" property value from the GAL/OAB and uses that to
deliver the message.

The settings and group memberships of the new users appear to match
those of the old for whom the email is operating correctly.

And what settings are those?

They are just security and distribution groups that have been set up.
The 'failing' accounts have the same group memberships as working
accounts.

Yes, but what are "the settings" you're looking at? Group memberships
are established by either manual or automated changes to the "members"
property of the group or the "memberOf" property of the user.

Try this:

Put the SMTP address of one of these mailboxes into the "To:" line of
a messae and hit Ctrk+K. Does the address turn into the "Display
name"? If it does, then address resolution is working okay.

I doubt that lineone.net is the domain of the users with the problems.
because that domain's MX record returns eight server in the
tiscali.com domain, and you've already said that you're using "direct
SMTP" (which means there are no SMTP relay servers that might be
rewriting the addresses). So, without the domain name to work with
you'll have to do all the testing. :)

From the keyboard of the Exchange server:
telnet 127.0.0.1 25
HELO
MAIL FROM: x@xxx
RCPT TO: problem.user@xxxxxxxxxxxxxxx
DATA
Subject: who gets this message

This should go to problem.user@xxxxxxxxxxxxxxx
and not to administrator.
..
quit

Now -- who got that message? The problem user or the administrator?

Not without some more information. Is the SMTP address on the RCPT TO
command the same as the on assigned to the user? You'll have to check
the SMTP Protocol Log to discover that -- the "To:" header (and all
the other RFC2822 headers) are too easily forged to be useful in
troubleshooting problems like this.

How can I enable this information in the SMTP log? (I would assume the
address is correct as the failing users can send OK and the return
address presented is as expected)

Enable logging on the property page of the SMTP Virtual Server. Make
sure that you get enough information to make the log file useful. If
you're unsure of what to log, check ALL the boxes for the properties
to be recorded.

Thanks for your input.

I am really scratching my head over this one...

That's because I think that there's something going on outside you
server's control.

--
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.pott@xxxxxxxxxxxxx
Or to these, either: mailto:h.pott@xxxxxxxxxxxxxxx mailto:melvin.mcphucknuckle@xxxxxxxxxxxxx mailto:melvin.mcphucknuckle@xxxxxxxxxxxxxxx
.