Email "To:" Aliases unavailable/missing

[ksDevGuy]

The "To" header list and UnknownHeaders list both seem to not capture the email alias used for inbound email being retrieved via Pop. The "To" list resolves to the base/actual email address only (ignoring what is otherwise in the headers originally).

[foens]

I am not sure what an email alias is. Could you provide an example?

[ksDevGuy]

Fantastic component first may I say!

To point, every email account on all mail servers may have alternate email addresses that it will accept email from besides the main address which are called "aliases". Example: support@abc.com might also have helpdesk@abc.com, prioritysupport@abc.com attached as valid inbound addresses to accept email for even if the mail is delivered to the support@abc.com email inbox physically. Outlook.com & Gmail.com provide this feature as another example.

Most web based and desktop app's such as Outlook allow you to see the original email address specified/used by the inbound message even if an alias (often with a hover, or right click or something). In the case of this excellent .NET component, it would make the difference for an application to share one email account across many clients via aliases for each client who could send email to the application using their unique email address (alias on a single email account) -- and the application would only have to access a single email inbox/account to collect messages from a potentially unlimited number of customers reliably (only one email account for IT to manage as well, just adding aliases when needed) and by reading the actual address the email was submitted to (not the resolved physical account containing that address) it would provide reliable, easily managed, multiple customer management for a software application (e.g. most HelpDesk applications use this alias reading technique to accomplish the task - that way no matter what email a customer uses you still know which customer is submitting to you without managing an ocean of email accounts on the IT side).

My apologies if I am describing things I am sure you already know, just trying to paint the use case against which the missing feature can be applied as example (one we are trying to do now with this otherwise fantastic component!).

Thanks.

[foens]

Sure, then I know what email aliases are. I would believe that the email header to would have the alias contained in it. Actually, I would think that the base email would not even be found in the email. Are you sure that your mail server does not alter the message, such that the to email header is modified to the base address? Maybe you could provide the headers of an email, and show where the alias and the base email is?

[ksDevGuy]

My thought as well, but for some reason no go. We are running Exchange 2013 SP1. Good suggestion, let me go grab one and see what it shows - more shortly. Thank you (again).

[ksDevGuy]

This sample email (I anonymized the addresses & IP's via search/replace) was from "mis@xyz.com" sent to alias "jdproperty@abc.com" on a physical email account "support@abc.com" (Sonicwall anti-spam on both sides so some extra headers of course) -- all the data is there but doesn't show in the component for some reason:

Received: from mail.abc.net (192.168.168.168) by mail.abc.net (192.168.168.168) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Mailbox Transport; Tue, 13 Jan 2015 18:31:30 -0800 Received: from mail.abc.net (192.168.168.168) by mail.abc.net (192.168.168.168) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 13 Jan 2015 18:31:17 -0800 Received: from mail.abc.net (192.168.168.168) by mail.abc.net (192.168.168.168) with Microsoft SMTP Server id 15.0.847.32 via Frontend Transport; Tue, 13 Jan 2015 18:31:17 -0800 Received: from mia0vm-cass05.colo.sonicwall.com ([208.17.117.5]) by mail.abc.net (SonicWALL 7.4.6.1939) with ESMTP id 201501140231160096331; Tue, 13 Jan 2015 18:31:17 -0800 Authentication-Results: mia0vm-cass05.colo.sonicwall.com;none Received: from mail.xyz.com ([173.197.69.2]) by mia0vm-cass05.colo.sonicwall.com (SonicWALL 8.0.7.2933) with ESMTP id 201501140230470042963; Tue, 13 Jan 2015 18:30:48 -0800 Received: from mail.xyz.com (10.10.10.10) by mail.xyz.com (10.10.10.10) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 13 Jan 2015 18:30:30 -0800 Received: from mail.xyz.com ([fe80::d07f:2f81:6824:4ad5]) by mail.xyz.com ([fe80::d07f:2f81:6824:4ad5%12]) with mapi id 15.00.0847.030; Tue, 13 Jan 2015 18:30:30 -0800 From: MIS mis@xyz.com To: "jdproperty@abc.com" jdproperty@abc.com Subject: Here is a repair needing to be done Thread-Topic: Here is a repair needing to be done Thread-Index: AQHQL6IQ8rxtEcx+v0yhcPMX97YKGg== Date: Wed, 14 Jan 2015 02:30:29 +0000 Message-ID: aea45ca2457748089dea75de048c5c20@mail.xyz.com Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [{public ip here}] Content-Type: multipart/alternative; boundary="_000aea45ca2457748089dea75de048c5c20mailjdpropertycom" MIME-Version: 1.0 X-Mlf-SPF: SPF Disabled (result=disabled;) X-Mlf-DKIM: DKIM Disabled (result=disabled;) X-Mlf-DMARC: DMARC Disabled (result=disabled;) X-Mlf-KeyWords: repair,complete,property,jd,detail,department,whats,wrong X-Mlf-Language-Detected: NoLanguageFilter_English X-Mlf-Connecting-IP: 173.197.69.2 X-Mlf-Country-Code: US X-Mlf-Rules: rn;4.15 X-Mlf-Rules-Pos-Features: WORD_jd_1.50;WORD_detail_1.25;WORD_department_1.13;WORD_whats_0.94;WORD_wrong_0. X-Mlf-Rules-Neg-Features: SUBJrepair-1.89;RE_RECEIVE_TIME=18_0.00;WORD_complete_0.42;WORD_property_0.62 X-Mlf-Sliderbars: N4,B4,S4,L4,Q4,G4,A4,I4 X-Mlf-Version: 8.0.7.2933 X-Mlf-Threat-History: nothreat X-Mlf-Threat-Detailed-History: nothreat;other;none;none X-Mlf-UniqueId-History: i201501140230470042963 X-Mlf-CassCloud: sn=0017C5C1F8BC;vr=3;ls=t;ds=d;lp=t;dp=d;lv=t;dv=d;js=1;do=none;jv=7.4.6.1939; X-Mlf-Connecting-IP: 208.17.117.5 X-Mlf-Country-Code: -- X-Mlf-Threat: nothreat X-Mlf-Threat-Detailed: nothreat;none;none;cloud-nj X-Mlf-UniqueId: i201501140231160096331 Return-Path: mis@xyz.com X-MS-Exchange-Organization-Network-Message-Id: c05380d0-7152-42d9-ba0b-08d1fdb94f6c X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 X-MS-Exchange-Organization-AuthSource: mail.abc.net X-MS-Exchange-Organization-AuthAs: Anonymous

[foens]

So, it seems only the alias is listed? But wasn't you complaining that the alias was missing? It seems the base address is not found, as I would expect.

[ksDevGuy]

Yes and yes. From Outlook Web Access (where I pulled the sample header) it shows what you see, yet when the same email is accessed from the component via POP off the Exchange server I get the support@abc.com addresses on every attribute - which is odd.

Let me run the our test harness again against that exact email and report back what I get for the To attributes. One moment, thanks.

[ksDevGuy]

I don't know what happened, but after hours if consistent failure last week -- it appears to be working now?! Nothing touched in either code or the mail server. My thought is .NET has a tendency to stubbornly cache strange things we have found over the years, and after server reboot or time for the run-time to unload/reload it magically starts giving you fresher data .... honestly, that is all I can imagine (as we originally coded/tested against the base email, then added aliases as the very last to-do item).

My apologies for wasting your time with this, we are truly appreciative of the component built and shared with the community (we too have done a little in like spirit in the VoIP space). So thank you very much.

[foens]

That sounds strange. The issue also sounded strange to me, so this eases my mind, a little. Well, good luck to your project :)

[ksDevGuy]

Maybe I found the issue? Here is a header that has the display name as "Support" and the email as jdproperty@abc.com yet the component returns "support@abc.com" for the email when queried. Any thought?

Received: from mail.abc.net (192.168.168.168) by mail.abc.net (192.168.168.168) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Mailbox Transport; Mon, 12 Jan 2015 12:19:15 -0800 Received: from mail.abc.net (192.168.168.168) by mail.abc.net (192.168.168.168) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 12 Jan 2015 12:19:14 -0800 Received: from mail.abc.net ([fe80::1535:8eca:7db1:81c2]) by mail.abc.net ([fe80::1535:8eca:7db1:81c2%12]) with mapi id 15.00.0847.030; Mon, 12 Jan 2015 12:19:14 -0800 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary From: IT Department mis@xyz.com To: Support jdproperty@abc.com Subject: My computer is broken Thread-Topic: My computer is broken Thread-Index: AQHQLqS7yDKCHPK0NUikgzD3ECU8uQ== Importance: high X-Priority: 1 Date: Mon, 12 Jan 2015 12:19:14 -0800 Message-ID: 90fa086cacfa45408e22c40b280341c4@mail.abc.net Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: 90fa086cacfa45408e22c40b280341c4@mail.abc.net MIME-Version: 1.0 X-MS-Exchange-Organization-MessageDirectionality: Originating X-MS-Exchange-Organization-AuthSource: mail.abc.net X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-Originating-IP: [{public IP here}] X-MS-Exchange-Organization-Network-Message-Id: 3c9d56b8-502b-480f-14c5-08d1fcbc2b36 Return-Path: mis@xyz.com X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0

[foens]

Are you 100% certain that the above mail is what OpenPop reads? If you save the message to a file in OpenPop, you should be able to open it with notepad or some similar program. The above mail dosn't even contain the support email...

[ksDevGuy]

This particular email is between tenant's on a multi-tenant hosted Exchange so the pathing is a little shorter. But let me do that and get back with those details as you suggest. Thank you.

[ksDevGuy]

Thank you again for the suggestion, I think it is an intra-Exchange issue -- multi-tenancy gets email resolved via GUID it appears to the native address rather than storing the more usual SMTP related info when mail comes from the outside. Will work on the IT side of this for more details, but for anyone finding this thread that may have a similar issue -- I think that is what is going on.

Thank you (yet again).