I have a customer service rep at iMail that might be willing to help. Says that they haven't heard about a problem with aliases in over a year?
Carl J. Carl Wagar EntreNet Communications Inc <http://www.entrenet.com> www.entrenet.com <http://www.thehostingservice.com> www.thehostingservice.com 24 Swain Ave, Ottawa, ON, K1G 4T1, Canada Email: <mailto:[email protected]> [email protected], skype: jcwagar Tel: +1 613-737-7327, Fax: +1 613-737-5801 Cel: +1 613-818-8898 From: [email protected] [mailto:[email protected]] On Behalf Of Andy Schmidt Sent: Wednesday, September 24, 2014 12:52 PM To: [email protected] Subject: [MBF] Re: DECLUDE vs. Address Book WhiteListing -> Two bugs Hi David, Actually, THAT only comes into play if an alias exceeds a certain number of ENTRIES (I forgot how many). That has ALSO always been this way. If an alias points to MULTIPLE email addresses, and it's more than "x" number of addresses, then it's automatically converted to a "list" (with the corresponding .LST file). Best Regards, Andy From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of David Barker Sent: Wednesday, September 24, 2014 12:44 PM To: [email protected] <mailto:[email protected]> Subject: [MBF] Re: DECLUDE vs. Address Book WhiteListing -> Two bugs Version 12.4.0.66 seems to be storing the alias in the root domain folders "aliasname".lst - there could be legacy structures that are involved with IMail upgrades as opposed to IMail new installs. I will pass along the information to our engineer. Thanks for the feedback. From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andy Schmidt Sent: Wednesday, September 24, 2014 12:30 PM To: [email protected] <mailto:[email protected]> Subject: [MBF] Re: DECLUDE vs. Address Book WhiteListing -> Two bugs Hi David, No difference, even in latest verison. Since the early days of Declude, alia have ALWAYS been stored as REG_SZ items here: [HKEY_LOCAL_MACHINE\SOFTWARE\Ipswitch\IMail\Domains\TheDomainName.com\Users\ _aliases] "postmaster"="[email protected] <mailto:[email protected]> " "hostmaster"="[email protected] <mailto:[email protected]> " etc. However, I THOUGHT Imail was "resolving" aliases and storing them in the Q file? Best Regards, Andy From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of David Barker Sent: Wednesday, September 24, 2014 12:17 PM To: [email protected] <mailto:[email protected]> Subject: [MBF] Re: DECLUDE vs. Address Book WhiteListing -> Two bugs Hi Andy, Declude only checks on user email address. With the changes in IMail the alias seems not to be stored in the database as previously or even stored in the database at all. We are working to confirm where the latest version of IMail stores aliases. As for Address whitelist for <mailto:[email protected]> [email protected], originally the implementation used the txt file which was accessible by the user to add this option. However since IMail moved to a database in later versions we are unclear as to where IMail is now storing this information. Obviously using the Declude whitelist options is a way to circumvent this. If anyone has insight into the storing of the alias information within IMail latest versions this would be helpful. David Barker Mail's Best Friend Email : [email protected] <mailto:[email protected]> Web : www.mailsbestfriend.com <http://www.mailsbestfriend.com/> Office : 866.919.2075 From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of David Barker Sent: Wednesday, August 27, 2014 6:49 PM To: [email protected] <mailto:[email protected]> Subject: [MBF] Re: DECLUDE vs. Address Book WhiteListing -> Two bugs Hi Andy, Got it. Will have dev look at it and give you some feedback based on findings. David On 8/26/2014 11:06 AM, Andy Schmidt wrote: Hi, Address-book whitelisting is a crucial feature, as it puts the user in control to decide which individual senders or which domains they want to trust. After spending a lot of time with customers and THEIR clients, them insisting that the whitelisting is not working no matter WHAT they tried, I've confirmed the following two bugs: 1. Addressbook Whitelisting attempts to find address book under the IMAIL ALIAS name, instead of resolving aliases to the proper IMAIL USER name! Example: [email protected] <mailto:[email protected]> is configured as an ALIAS for [email protected] <mailto:[email protected]> Emails addressed to aec@... will NOT be whitelisted, but emails addressed to "Anthony_Cuomo" will be whitelisted: Did not find [ [email protected] <mailto:[email protected]> ] in [ [email protected] <mailto:[email protected]> ] address book Finish Address Book WhiteList Vs. Skipping4 E-mail from [email protected] <mailto:[email protected]> ; whitelisted [[email protected] <mailto:[email protected]> ]. Finish Address Book WhiteList Obviously, Declude must NOT use the ALIAS name to attempt finding (non-existing) Address Books, it must use the Q file to learn the "final" delivery USER name, and use THAT for Addressbook validation! 2. The original implementation of the Addressbook Whitelist (by Scott) had allowed for a generic domain whitelist, by using: [email protected] <mailto:[email protected]> to whitelist ANY email addresses ending with "@sender.com". When the addressbook lookup was converted to the current Imail Contact Database, someone forgot to implement the proper SQL query that checks the recipient's address book for the FULL match of EITHER, "individual_senderl <mailto:[email protected]> @sender.com" OR "[email protected] <mailto:[email protected]> " Since whitelisting is so critical in any "blacklisting" solution (like Declude), I would ask that both these bugs be addressed - and certainly am willing to put my money where my mouth is - whether through purchasing additional "support" tickets or whatever other requirements you have. Best Regards, Andy
