Page 1 of 1

ALIAS not working

Posted: 2014-07-31 12:51
by jimimaseye
I have just set up an ALIAS for an address eg, random@mydomain ---->

The I sent in an email to random@mydomain but it didnt get redirected to

Full picture:
the mail is picking up via external download POPing (rather than direct inbound smtp) from our domain hosts email server. They have a 'catch all' redirect that sends all email to random@mydomain ---> (still on their server). It is THIS real account that gets POPd by my server ''.

I suspect the ALIAS feature on HMS is not using the real RECIPIENT list of the email, and is actually using the account to evaluate the alias instead.

ie, because it is the account that is doing the email pickup from the external server, it considers that the email has been sent to "" and therefore doesnt require ALIAS evaluation or redirection.

It should be looking at the actual emails recipient list and seeing it was for random@mydomain and making the alias redirect accordingly (just like it would if it were being received directly as an inbound SMTP message).

This evaluating based on the account rather than the actual email itself has cropped up and caused problem with other things in the past too and this is why I suspect this is the same thing.

Note: I have tried the ALIAS test by receiving the email as an inbound SMTP message rather than External Download and it does work ok.

(I think I should log this)

Re: ALIAS not working

Posted: 2014-07-31 14:25
by percepts
have you ticked "Deliver to recipients in Mime Headers" in your external download settings. That should deliver to whoever is in To: and Cc: I think.

Note there is no SMTP envelope recipient list as far as I'm aware as this is POP and not SMTP. i.e. it just puts the mail in the downloading inbox except for above selectable option. You are pulling mail and not sending it when you do a pop fetch and you are always pulling it to a specific iNBOX. That's what POP does.

Re: ALIAS not working

Posted: 2014-07-31 15:08
by jimimaseye
The 'Deliver to recipients in Mime Headers' option did the trick.

It leaves me with a problem though which means I cant really use it as an option.


Email sent in to recipients:
to: account1@mydomain
cc: account2@mydomain
cc: alias@mydomain

account1 will POP external server for the account1 mail
account2 also POPS for account2 mail

account1 will then deliver an email to ACCOUNT1, ACCOUNT2 and the relevant alias redirect account. (This is good).
But then account2 will do the same (as the recipients headers show on both emails). So I receive 2 copies of the email in both account1 and account2. (This is NOT good.)

So I cant use 'Deliver to recipients in Mime Headers' as the solution.

Re: ALIAS not working

Posted: 2014-07-31 15:13
by percepts
Yes you have a problem. And that problem has been created by your own contrived method of receiving mail at your ISP and delivering it to hMail. You need to think again.

even if you wrote a script I doubt it would work.

e.g. a mail with several addresses in To: header. Since each of those would have its own mail in your isp inbox there would be several mails downloaded by pop. But you wouldn't know which one in the list you were processing so couldn't exclude the others. i.e. your concept is flawed from the start,

Re: ALIAS not working

Posted: 2014-07-31 16:58
by jimimaseye
Indeed, yes, that is what I was explaining. I accept the restriction. However, I dont really need to think again about my 'contrived' method for 2 reasons:

1, I could simply write a rule for any account I would choose to create an Alias to say 'if TO or CC contains [alias address] then forward to [real address]. This is pretty much what the alias feature does when receiving the mail directly. (Writing a rule of this type is hardly a hassle)
2, my method has double (or even more) security than having my box receiving inbound SMTP mail deliveries directly
a, if my server/office goes up in flames, I would lose all emails that have been received since last backup. But *I* would have all the emails still on file at the host system (currently set to 31 days but could go back 6 months or more if I wanted). So a recovery/replacement machine, + a restore of last backup + the first poll/download since recovery = full receipt of ALL emails right up to the moment the machine went up in flames PLUS ALL EMAILS SENT TO US DURING THE TIME of performing the disaster/system recovery . (How many of you with inbound SMTP deliveries can say that?)
b, as my host already scores with spamassassin the emails when they receive them, should my spamassassin scoring fail locally (which normally overwrites their SA headers with my own preferred scoring system and can occasionally happen) the emails will still contain SA scoring on them
c, the hosts email service should have more powered systems and ability to handle and reject the constant sniffing and intrusion that spambots attempt. It means I dont have to worry about this.
d, as the host provide a readymade webmail service, I dont have to risk my server further by applying IIS/web service and ports (not to mention the cost implications and resources). Furthermore, EACH user can still access via webmail THEIR OWN account emails should they not have a configured client with them.
e, if hosts email system stops working, I simply create an MX record and point it to my machine. And emails continue. (30 seconds).
Having inbound SMTP mail to my server will do nothing that the hosts email server cant do except be less secure for me.

It might be *contrived* but it was contrived for a reason. It works for me and could also work for others.

Re: ALIAS not working

Posted: 2014-07-31 17:50
by percepts
thats fine if you only have a handful of local accounts but a pain if you have a lot and a large turnover of staff.

Re: ALIAS not working

Posted: 2014-07-31 17:57
by jimimaseye
Hi Percepts

Yes, that would be true. It does mean that every account needs to be set up twice: once here on a local box and then once with the hosting service. But I would also think that it actually only takes seconds on the hosting site (once logged in, click EMAIL, click ADD NEW USER, type in the username, click OK). And the there's the 40 seconds it takes to create the External Download details on the new user in HMS.

It is true its longer than not doing it, but not so long to negate the benefits of the added security me thinks. (I am interested to know though, as its not my situation, what kind of numbers and staff turnover are you talking that the above procedure and extra 2 minutes per user would make it unfeasable?

(Ive worked for a global organisation where the corporations employees were all controlled through IT headquarters in the UK. And it took longer to write out the forms requesting server access and a profile than it did actually setting them up.)

Re: ALIAS not working

Posted: 2014-07-31 18:15
by percepts
if you only have say upto 50 or so employess it migh be managable but if you have several hundred it would be a pain and your server has to process the script for each mail which all arrive at the same time when you do the external download.

Do you send out using ISP as outgoing relay or if you did would each sender require an account on ISP?

and is ISP mail done using cpanel ?

Re: ALIAS not working

Posted: 2014-07-31 19:15
by jimimaseye
I dont think they use cPanel but cant be sure. Ive never seen it (cPanel) myself, Ive looked at screenshots, but am unsure on how 'tailorable' in its appearance it is. They certainly dont brag that its cPanel.

All outgoing mail is handled by HMS - no smtp relay is used. The only reliance on the hosts mail server is the initial collation of email. HMS then polls it every so many minutes (5 I think). Polling so frequently reduces the amount of emails it would be picking up and processing each time.

Admittedly if there were several hundred email accounts then that would be several hundred POP connections all at once (potentially). But I think in this case I would have a single 'collation' account on the host server where HMS would poll and then sort internally (using the delivery to MIME recipients we discussed at the start of this thread). That would mean less POP connections simultaneously (in fact, only 1) but of course a potentially higher number of emails to retrieve at any one time.

I dont think there is a text book solution because there are too many variables to consider. (POP connections allowed simultaneously to the host server, number of email accounts, disk space/historical emails allowed on the host server, power of our internal main server (to handle the processing of the emails when they arrive in such 'bulk'). I reckon it would be a gradient between what I have now and eventually moving towards total handling internally without the external host server after the variable have been evaluated and tests for handling the solution performed. For example, give a huge ADLS pipe, an unlimited disk space on the host mail server and a Google-strength server (whatever they use) as a mail server, then why not continue with my current set up irrespective of having thousands of accounts? (there are no restrictions). But of course, personally, I dont. And in fact we are low in terms of power but its sufficient for the amount of accounts and mails we have. You might have a server that is a lot more powerful and could operate the same way but only up to, say, 100 accounts.

How does it fit your situation or what would be your restrictions for your set up?

Re: ALIAS not working

Posted: 2014-07-31 19:21
by percepts
I'm the only user on my server and my usage is extremly light so I have no problems with volume of any kind. As regards security, I don't expect email internationally except with a few minor exceptions so my server is only open to my own country which instantly reduces 99% of attempted security hacks and spam. I just don't receive any.

Re: ALIAS not working

Posted: 2014-07-31 23:24
by mattg
Why don't you just have a SINGLE externally hosted account (a catch all) and have a single hMailserver account do an external account download...

Re: ALIAS not working

Posted: 2014-07-31 23:38
by jimimaseye
As stated above,:
jimimaseye wrote:d, as the host provide a readymade webmail service, I dont have to risk my server further by applying IIS/web service and ports (not to mention the cost implications and resources). Furthermore, EACH user can still access via webmail THEIR OWN account emails should they not have a configured client with them.
Having a single account on the external host server would negate everyone having private webmail access to their emails.

Re: ALIAS not working

Posted: 2014-07-31 23:45
by ^DooM^
Could you perhaps do away with the alias and work it this way instead.

Setup a catch all account to a single email address which will catch any email not to a hosted account. Then setup an account level rule to forward email that matches a recipient (Use CONTAINS), to the correct mailbox. (Basically doing what an alias would do but with rules instead)

Might not work, but it's another angle to try.

Re: ALIAS not working

Posted: 2014-07-31 23:52
by mattg
jimimaseye wrote:As stated above,:
jimimaseye wrote:d, as the host provide a readymade webmail service, I dont have to risk my server further by applying IIS/web service and ports (not to mention the cost implications and resources). Furthermore, EACH user can still access via webmail THEIR OWN account emails should they not have a configured client with them.
Having a single account on the external host server would negate everyone having private webmail access to their emails.
Then why are you using hMailserver?

Perhaps you could host your own webmail...
or perhaps you could script to remove the subsequent local addresses from mail downloaded via External POP3 fetch

ultimately, this is caused by the fact that you have the same accounts set on two servers.

Re: ALIAS not working

Posted: 2014-07-31 23:57
by ^DooM^
it's quite clever from a security perspective, You get that disconnect between yourself and an outside MTA. As far as the email world is concerned your front facing mail servers are Here, and your own servers are hidden away in the background.

Not that i'm paranoid or anything :D

Re: ALIAS not working

Posted: 2014-08-01 00:33
by jimimaseye
Doom (re: catchall account then using rules):

Yes, in fact that is what I said earlier in the thread that I will do. I have tested it and it works fine actually. As we said, the 'alias' built in feature is nothing more than a rule thats already done the IF...THEN clause for you (we simply have to supply the variable values (email addresses) to complete it).

Matt: I understand why you would ask.
My post earlier explains the benefits - being both of security and cost. I already agreed that my setup is the cause of my failure to use the BUILT IN alias feature, but the workround about writing the rule myself is done in two ticks so really no big deal. Also I said, why introduce risk and cost by fannying around setting up webside access to my server when there is a webmail system hosted my my domain host providing a perfectly good one. After all neither they nor I would be able to achieve anything more than providing, err, webmail (in other words, neither can do any more than the other). So why duplicate?

Re: Why use HMS on my own server?

a, For handling and storage of FULL historical, searchable and referable mail (disk space is virtually unrestricted compared to the cost of 'buying' space with the host (email quantity is far more than the host will permit without extensive costs)
b, Control and tailoring of personalised Rules and filters
c, Control and tailoring of personalised spam checking and scoring
d, Internal network speed (a MAJOR factor) - consider opening an email with large attachment and compare the speed between it being local (on a 1gigabit network) and being hosted at the end of a 16mb ADSL line.

(Im listing these benefits for other readers as Im sure you dont need me telling you, Matt)

or to put simply..... for the same reason you and all other users do. Ive simply added the extra security of having my mail storage copies doubled, accessibility doubled, hardware/software costs lowered and the risks quartered. (Something that makes the very minor hassle of having to do the odd manual rule for aliasing worth doing).

I thought about it a lot and tailored and tested over the last 2 or 3 years between full domain hosting mail control, full internal HMS control, and then something in between. And in the end I settled for this system for ALL of the benefits I listed earlier (in this post: ... 9#p164269) I think it makes a lot of sense. (I am of course open to discussion about potential pit falls if you or anyone has any).

Hope this clarifies.

Re: ALIAS not working

Posted: 2014-08-01 03:34
by mattg
I'm guessing that email sent between your local users, doesn't show up in the hosted webmail.

Re: ALIAS not working

Posted: 2014-08-01 09:13
by jimimaseye
Yes thats right. I guess it could be ideal for some organisations but its really not a problem for ours; there is little to no inter-company emailing between staff that would be important to be available if and when the webmail service has to be relied upon. Remember that the webmail service is only really used AFTER all other methods are not available. ie, when the following is true:

a, not sitting in the office (using the office PCs)
b, not working remotely with company laptop (preconfigured with email client for HMS IMAP access)
c, not actually carrying around their smartphone (preconfigured with HMS IMAP access for their account).

You see, in reality, the chances of webmail being called upon is slim-to-zero given that most people find it easier just to launch their email app on their phone or ipad (everyone has it). (I am probably the main user of it as it has an automatic 'report spam' button for reporting to Spamcop - something that I doubt I will need for inter-office emails. I hope! :shock: )

It is do-able though. I already do have emails from one of our domains on our server being sent out and back in to our other domain (rather than just 'across' internally) purely for the reason have having them there and available on the external host.
ie, sends an email to (we are in the UK)

normally it would simply be transferred internally and therefore not show up on the external server. But by using ROUTES that email is actually sent out to the external host server (thereby being picked up by them) which then gets POPd and comes back in to account. It works well actually. The only downside is that the transfer takes the time of my POPing interval rather than be immediate (as it would just going internally). The beauty of this, matt, is that I think it was you that helped me do this. :-)

(Not related, but to clarify for readers, all SENDING of emails goes directly from our server - no SMTP relay is used. The domain hosts mail server is only used for collecting incoming mail)