Email "To:" Aliases unavailable/missing about hpop HOT 13 CLOSED

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

from hpop.

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: [email protected] might also have [email protected], [email protected] attached as valid inbound addresses to accept email for even if the mail is delivered to the [email protected] 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.

from hpop.

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?

from hpop.

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).

from hpop.

This sample email (I anonymized the addresses & IP's via search/replace) was from "[email protected]" sent to alias "[email protected]" on a physical email account "[email protected]" (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 [email protected]
To: "[email protected]" [email protected]
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: [email protected]
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="000_aea45ca2457748089dea75de048c5c20mailjdpropertycom"
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: SUBJ_repair_-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: [email protected]
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

from hpop.

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.

from hpop.

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 [email protected] 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.

from hpop.

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.

from hpop.

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

from hpop.

Maybe I found the issue? Here is a header that has the display name as "Support" and the email as [email protected] yet the component returns "[email protected]" 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 [email protected]
To: Support [email protected]
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: [email protected]
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: [email protected]
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: [email protected]
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0

from hpop.

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...

from hpop.

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.

from hpop.

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).

from hpop.