I've had compliants by phone from clients who can't reply to our emails. When I look at the email, the address has been altered, always in the same way: first.surname_at_domain.com becomes first.surname_at_www.domain.com. We're at a loss to explain it. I can send an email to a client and to my own gmail address and the return address on the mail arriving at Gmail is fine but at the address corporate client is corrupted by the inclusion of www. We had this problem with SBS2003 and now SBS2008 which was a complete replacement rather than a migration. I did 2003 but SBS2008 was done by a partner who does Exchange and SBS exclusively. We're confident that the email addresses in our exchange server have never included a www, so where has it come from and how do we cure it? I've explained to them that the emails are fine when they arrive at Gmail and that it is mainly recipients who are using Exchange who are impacted by this but that it isn't exclusively Exchange - sometimes we get complaints from Yahoo recipients. Have any of you seen this before and know how to fix it?

FWIW two things changed last year but I'm not sure whether they have any bearing on this: 1) We moved to Outlook 2010 2) I moved our domain registration from Netsol to a cheaper one This problem occurs regardless of whether the mail is sent by Outlook or OWA I'm wondering if the addresses held by corporates have been cached in a corrupted form and now everything from that sending domain has the corrupted address inserted over the genuine one. Also. it seems to be all senders from our domain whose recipients have this problem.

Email address caching doesn't happen. The closest that you get is contacts in Exchange which can be configured incorrectly and will overwrite certain things. This isn't something I have seen before. Therefore it is either an error made somewhere, or something that has remained in place across migrations. Therefore, first, check your Email Address Policy and accepted domain to ensure that format is not listed. Second - how does outbound email get routed? Directly by MX record delivery, or through a smart host? If through a smart host then that is where I would be pointing the problem. Highly unlikely to be Exchange unless the email address policy is wrong because Exchange cannot do address rewriting without a third party application or an Edge server. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources

On Sun, 9 Jan 2011 09:24:25 +0000, Smiling Eddie wrote: >I've had compliants by phone from clients who can't reply to our emails. When I look at the email, the address has been altered, always in the same way: first.surname_at_domain.com becomes first.surname_at_www.domain.com. We're at a loss to explain it. I can send an email to a client and to my own gmail address and the return address on the mail arriving at Gmail is fine but at the address corporate client is corrupted by the inclusion of www. Are you referring to the SMTP "RCPT TO" addresses, or to the addresses in the "From:" header of the message as it's seen at the destination mailbox? >We had this problem with SBS2003 and now SBS2008 which was a complete replacement rather than a migration. I did 2003 but SBS2008 was done by a partner who does Exchange and SBS exclusively. We're confident that the email addresses in our exchange server have never included a www, so where has it come from and how do we cure it? I've explained to them that the emails are fine when they arrive at Gmail and that it is mainly recipients who are using Exchange who are impacted by this but that it isn't exclusively Exchange - sometimes we get complaints from Yahoo recipients. > >Have any of you seen this before and know how to fix it? I think you need to identify WHERE the chage is occuring. The fastest way to do that would be to use a network monitor (WireShark is pretty easy to use) and capture the data as it leaves your Exchange server. If everything looks good as it's leaving Exchange then you can probably point your finger at the receiving domain (unless you have other SMTP relays/proxies that handle your mail after it leaves Exchange). A good bet would be that they're rewriting the "From:" headers. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich, I agree, it would be a useful start to work out where the change occurs. But when I sent an email to multiple recipients and some recieve it with the correct address while others do not, where do I start? If I use the Exchange Troubleshooter to track emails that I know had the problem, the return path address is correct. For wireshark to show me something different, the return path would have to be corrupted between the message being recorded in Exchange and being released onto the network. But if it did that, surely none of the clients would recieve the email with the correct return address. I can't see how anything in my Cisco IOS router would modify this part of my message. Postini, who filter incoming and out-going mail for us insist that there is nothing being changed in their section of the path. I think that if we could explain why some email clients have the problem and other don't, we'd be much closer to fixing thiis. Complaint from a customer again today, so here I am in desperation once more.

On Mon, 31 Jan 2011 19:33:17 +0000, Smiling Eddie wrote: >I agree, it would be a useful start to work out where the change occurs. But when I sent an email to multiple recipients and some recieve it with the correct address while others do not, where do I start? If I use the Exchange Troubleshooter to track emails that I know had the problem, the return path address is correct. For wireshark to show me something different, the return path would have to be corrupted between the message being recorded in Exchange and being released onto the network. But if it did that, surely none of the clients would recieve the email with the correct return address. Whether that's true or not depends on what's rewriting the addresses. If there's any 3rd-party software running on the Exchange server it may have hooked port 25 and the addresses are changed after the information's logged by Exchange. The point is that you don't know what's going on yet -- the point of using the network monitor is to eliminate the Exchange server (or implicate it). >I can't see how anything in my Cisco IOS router would modify this part of my message. Postini, who filter incoming and out-going mail for us insist that there is nothing being changed in their section of the path. I think that if we could explain why some email clients have the problem and other don't, we'd be much closer to fixing thiis. You can't fix it until you know where it's happening (or eliminate the pieces under your control). >Complaint from a customer again today, so here I am in desperation once more. Doing nothing will certainly ensure you remain in that state. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Again, I think you're right so I've downloaded and installed Wireshark on my desktop. I'll do some proper tests tomorrow night - ran out of time tonight because the day job. I am quite keen to see if it really is dequeueing some copies an email with the intended address and some with one that it has corrupted. Exchange is running on a standard SBS 2008 system with no third party tools on at all. Is it just a matter of capturing what flows out through port 25 while I'm sending or is there more I need to be doing as well?

On Mon, 31 Jan 2011 23:34:25 +0000, Smiling Eddie wrote: > > >Again, I think you're right so I've downloaded and installed Wireshark on my desktop. I'll do some proper tests tomorrow night - ran out of time tonight because the day job. I am quite keen to see if it really is dequeueing some copies an email with the intended address and some with one that it has corrupted. > >Exchange is running on a standard SBS 2008 system with no third party tools on at all. > >Is it just a matter of capturing what flows out through port 25 while I'm sending or is there more I need to be doing as well? If you have an email address that's consistently rewritten you can reduce the volume of data that will be captured by collecting data only for a particular host IP address or maybe just a part of an entire network. But, yes, you're going to capture the data and look at it later, so if you're going to run the software on the server be sure you don't set the capture to work in promiscuous mode and that you have enough storage to accomodate the capture. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

There may be tricks in Wireshark that I've yet to discover and some will probably be fairly basic. I can see it establishing a connection to Postinii and the steps of a TLS handshake taking place. After that, as expected, there isn't much to see that makes sense - its shoveling data off to Postini but I can't see the content, so the big strings of characters I had hoped to see in the capture just weren't visible. It was interesting to see that version sent to my Galaxy S is running as https. I think my next option is to ask Postini to tell me what they see emerging at their end of the tunnel when, I send to known good and bad addresses. Do you agree this is my best next step? Do you have another suggestion?

On Tue, 1 Feb 2011 23:15:17 +0000, Smiling Eddie wrote: >There may be tricks in Wireshark that I've yet to discover and some will probably be fairly basic. You can use the display filter to show you only "RCPT TO" commands. You could even make that a more selective filter by having it look for only the rewritten address. >I can see it establishing a connection to Postinii and the steps of a TLS handshake taking place. After that, as expected, there isn't much to see that makes sense - its shoveling data off to Postini but I can't see the content, so the big strings of characters I had hoped to see in the capture just weren't visible. Unless you're using TLS the message content is just text -- unless it's been base64-encoded. >It was interesting to see that version sent to my Galaxy S is running as https. > >I think my next option is to ask Postini to tell me what they see emerging at their end of the tunnel when, I send to known good and bad addresses. That wouldn't hurt. >Do you agree this is my best next step? Do you have another suggestion? if you have your log file and it shows address z@y.z and it's being delivered to a@b.c then Postini should be seeing a@b.c. It's as starting place. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

When I tried Wireshark, I was quickly reminded that the link from my SBS server to Postini is encrypted. I watched the stages of the authentication and key exchange but got no sight of anything meaningful in the data that was sent. I spoke to Postini today but their log doesn't show the Return-path value, so I can't see if it is intact when it emerges at their end of the encrypted tunnel. The From field is correct however, even for the message sent to a known problem recipient. I've changed the domain of the problem recipient to customer and mine to mydomain. I've also changed my surname where necessary and I've altered external IP addresses, but below is a copy of the email header as it appears to a known problem recipient. Does this tell you more about the nature of my problem? Microsoft Mail Internet Headers Version 2.0 Received: from avoexs02.internal.customer.com ([1nn.2nn.4.1nn]) by t1-MBX22.internal.customer.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Feb 2011 23:17:27 +0100 Received: from ukwmxc01.t1-uk.internal.customer.com ([10.33.126.160]) by avoexs02.internal.customer.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 23:17:27 +0100 Received: from UKWCS11.t1-uk.internal.customer.com ([10.102.3.241]) by ukwmxc01.t1-uk.internal.customer.com with Microsoft SMTPSVC(5.0.2195.7381); Tue, 1 Feb 2011 22:17:25 +0000 Received: from mailgate1.customer.co.uk (unverified) by UKWCS11.t1-uk.internal.customer.com (Clearswift SMTPRS 5.2.9) with ESMTP id <T9aefb6016b0a6603f11b28@UKWCS11.t1-uk.internal.customer.com> for <edward.mysurname@t1.uk.customer.com>; Tue, 1 Feb 2011 22:17:26 +0000 Received: from mail03.customer.com (mail03.customer.com [1nn.2nn.2nn.8]) by mailgate1.customer.co.uk (8.13.8/8.13.8) with ESMTP id p11MGtXc032750 for <edward.mysurname@t1.uk.customer.com>; Tue, 1 Feb 2011 22:16:55 GMT Received: from mail03 (localhost [127.0.0.1]) by mail03 (Postfix) with ESMTP id B45B01D22BA for <edward.mysurname@customer.com>; Tue, 1 Feb 2011 23:17:23 +0100 (CET) Received: from eu1sys200aog118.obsmtp.com (eu1sys200aog118.obsmtp.com [207.126.144.num1]) by mail03 (Postfix) with SMTP id 5594A1D2299 for <edward.mysurname@customer.com>; Tue, 1 Feb 2011 23:17:23 +0100 (CET) Received: from source ([80.229.197.148]) (using TLSv1) by eu1sys200aob118.postini.com ([2nn.1nn.1mm.1nn]) with SMTP ID DSNKTUiGcwpeRpMYN+F3BnLmfVriYe49OzTx@postini.com; Tue, 01 Feb 2011 22:17:23 UTC Received: from SBSSVR01.mydomain.local ([fe80::59db:586:ffc8:f951]) by SBSSVR01.mydomain.local ([fe80::59db:586:ffc8:f951%10]) with mapi; Tue, 1 Feb 2011 22:17:17 +0000 From: Edward mysurname <edward.mysurname@www.mydomain.com> To: "edward.mysurname@customer.com" <edward.mysurname@customer.com>, "smilingeddie@gmail.com" <smilingeddie@gmail.com> Date: Tue, 1 Feb 2011 22:17:14 +0000 Subject: Test AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Thread-Topic: Test AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Thread-Index: AcvCXcd/pPhgftXZQ0CvHEulrE1vVg== Message-ID: <2A2BCA665E5AB646AE0757FAD23358F2271C393FB5@SBSSVR01.mydomain.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_2A2BCA665E5AB646AE0757FAD23358F2271C393FB5SBSSVR01mydomain_" MIME-Version: 1.0 Return-Path: edward.mysurname@www.mydomain.com X-OriginalArrivalTime: 01 Feb 2011 22:17:25.0877 (UTC) FILETIME=[CE481A50:01CBC25D] --_000_2A2BCA665E5AB646AE0757FAD23358F2271C393FB5SBSSVR01mydomain_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_2A2BCA665E5AB646AE0757FAD23358F2271C393FB5SBSSVR01mydomain_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_2A2BCA665E5AB646AE0757FAD23358F2271C393FB5SBSSVR01mydomain_--

On Wed, 2 Feb 2011 19:21:04 +0000, Smiling Eddie wrote: >When I tried Wireshark, I was quickly reminded that the link from my SBS server to Postini is encrypted. I watched the stages of the authentication and key exchange but got no sight of anything meaningful in the data that was sent. I spoke to Postini today but their log doesn't show the Return-path value, so I can't see if it is intact when it emerges at their end of the encrypted tunnel. The From field is correct however, even for the message sent to a known problem recipient. The return path is set by the server that delivers the message to the mailbox. It shouldn't be present in messages that Postini handles. However, the "Return-path" is almost always the address in the "MAIL FROM" command. Surely they'd have that! >I've changed the domain of the problem recipient to customer and mine to mydomain. I've also changed my surname where necessary and I've altered external IP addresses, but below is a copy of the email header as it appears to a known problem recipient. > >Does this tell you more about the nature of my problem? [ snip ] It would seem to me that the *recipient* address is transformed on the server "mail03" within Postini. Is that what you're looking for, the transition from edward.mysurname@customer.com to edward.surname@t1.uk.customer.com ? Received: from mail03.customer.com (mail03.customer.com [1nn.2nn.2nn.8]) by mailgate1.customer.co.uk (8.13.8/8.13.8) with ESMTP id p11MGtXc032750 for <edward.mysurname@t1.uk.customer.com>; Tue, 1 Feb 2011 22:16:55 GMT Received: from mail03 (localhost [127.0.0.1]) by mail03 (Postfix) with ESMTP id B45B01D22BA for <edward.mysurname@customer.com>; Tue, 1 Feb 2011 23:17:23 +0100 (CET) If you're looking to see if the "From: Edward mysurname <edward.mysurname@www.mydomain.com>" is changed to from something else to "edward.mysurname@www.mydomain.com" I can't tell from this. Your SMTP protocol log will show you the "MAIL FROM" address (which is almost always the same as the address in the "From:" header), but if you want to see the contents of the message body (so you can see the RFC2822 headers) you'll have to enable pipeline tracing on your server and use your SMTP address as the sender's address to trace. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I'm learning a bit as we go here, so thanks for that. The transition that I'm really interested in is the one where the value given as my return address (bolded in my list of email addresses on my SBS server), edward.mysurname@mydomain.com is being translated into edward.mysurname@www.mydomain.com. The internal transitions associated with edward.mysurname@customer.com don't seem important to me - the mail is delivered successfully. Postini are convinced the translations are not happening in their part of the path. They've suggested that this is taking place at the recipient email servers and is probably related to some form of DNS corruption. Does this seem likely to you, and if so, can you suggest why or where the www bit has come from? I know that the CNAME I have is www.mydomain.com but could that have impacted our emails?

On Wed, 2 Feb 2011 23:39:10 +0000, Smiling Eddie wrote: >I'm learning a bit as we go here, so thanks for that. The transition that I'm really interested in is the one where the value given as my return address (bolded in my list of email addresses on my SBS server), edward.mysurname@mydomain.com is being translated into edward.mysurname@www.mydomain.com. The internal transitions associated with edward.mysurname@customer.com don't seem important to me - the mail is delivered successfully. > >Postini are convinced the translations are not happening in their part of the path. They've suggested that this is taking place at the recipient email servers and is probably related to some form of DNS corruption. Does this seem likely to you, and if so, can you suggest why or where the www bit has come from? I know that the CNAME I have is www.mydomain.com but could that have impacted our emails? If you're satisfied that neither you nor Postini are altering the "From:" header's address, then you'll have to move your investigation to the client's system. Is the client's e-mail system also running Exchange? If it is, the first thing I'd look for is whether or not the "edward.mysurname@www.mydomain.com" address is present in their directory. A simple LDAP query ("proxyaddresses=smtp:edward.mysurname@www.mydomain.com") would discover that in short order. If you find that then removing it should fix your problem. If you don't find that edward.mysurname@www.mydomain.com address then have a look at their SMTP logs and see if the MAIL FROM address is edward.mysurname@www.mydomain.com or edward.mysurname@mydomain.com. If ther MAIL FROM is correct then you can enable pipeline tracing on their system and see what's in the "From:" header at the various stages of the pipeline. If they're running Exchange 2007/2010, make sure that the receive connector isn't trusting unauthenticated SMTP sessions. To do so means, among other things, that the "P2" headers ("From:", "Cc:") will be "resolved". That's where the "edward.mysurname@www.mydomain.com" address might be found in the directory and replaced by whatever address they have as the targetAddress. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP