HOWTO force scalix to use SMART_HOST for ALL emails?

[jaime.pinto]

Many posts on similar topics, most of them on smarthost configuration not working.
My situation is unlike anything I've seem on this forum so far.

My smarthost is the primary MX entry for our domain and the main mail server for our organization. It will remain as such for many months to come. It has anti-spam/.anti-virus, a number of specially crafted filters for several purposes, as well as certificates, domainkeys, etc, etc. and works perfectly for what it does.

I have configured it in such way that for every email sent to our domain a copy stays with the old, solid and trustful mailserver, and another copy is forwarded to a selected number of users in the scalix server.

Scalix is configured for a small number of users, only MAPI clients, and for most cases it is using the smarthost properly, except for "internal users". In this case, any email of the format user@ourdomain.com gets "sucked" into the scalix server, and never actually gets sent via the smarthost, therefore never reaching the other internal users.

So question is: how to get scalix out of the business of sending emails directly, period, for all users, including the ones in scalix server?

Thanks for any ideas.
Jaime

PS: any suggestions to add forwarding instruction for every other user on the scalix server won't work, first because it's not practical, second due to circular forwarding.

[fraserm]

Many posts on similar topics, most of them on smarthost configuration not working.
My situation is unlike anything I've seem on this forum so far.

My smarthost is the primary MX entry for our domain and the main mail server for our organization. It will remain as such for many months to come. It has anti-spam/.anti-virus, a number of specially crafted filters for several purposes, as well as certificates, domainkeys, etc, etc. and works perfectly for what it does.

I have configured it in such way that for every email sent to our domain a copy stays with the old, solid and trustful mailserver, and another copy is forwarded to a selected number of users in the scalix server.

Scalix is configured for a small number of users, only MAPI clients, and for most cases it is using the smarthost properly, except for "internal users". In this case, any email of the format user@ourdomain.com gets "sucked" into the scalix server, and never actually gets sent via the smarthost, therefore never reaching the other internal users.

So question is: how to get scalix out of the business of sending emails directly, period, for all users, including the ones in scalix server?

Thanks for any ideas.
Jaime

PS: any suggestions to add forwarding instruction for every other user on the scalix server won't work, first because it's not practical, second due to circular forwarding.

Does your scalix system contain a list of all your users or only those selected users that are actually using it?

If scalix knows the message is for a user who exists locally, it's going to bypass "sending" the message completely. I doubt there's a way around it.

[jaime.pinto]

The only scalix users are the ones that require calendar for now, ie. a small subset of all users in the organization.

[kanderson]

Jaime is correct.

Mapi clients will send mail to the Scalix server, and if the recipient is local, the message will simply be delivered. It will not go to a smarthost because it's already on the destination server.

What do you need from the smarthost?

Kev.

[fraserm]

I believe we are running the same configuration...

He has scalix setup for some users, with smarthost configured to his primary mail server. I believe he's saying that when a scalix user tries to email someone that is on the primary mail server it's not going through.

[jaime.pinto]

I have just addressed the situation of scalix users trying to send emails to other users on the same domain, but that are not scalix users: I removed the "domain.com" from scalix list of domains, and left "scalixserver.domain.com".

Of course, this created a whole host of other problems, such as every From/reply-to field of all scalix users are (were) set to user@scalixserver.domain.com

I have addressed that as well, by tricking sendmail to use masquerade envelope and localdomain. etc .... I even found in this forum a trick to let users change their own reply-to field from the options menu.

But I'm still back to the same issue now:
Internal scalix users sending emails to each other never leave the local scalixserver, therefore a copy is not left on the "corporate" server. Just putting a forward in scalix will create a loop scenario since there is already an instruncion there to send emails to scalix.

Thanks for any help. I'd still like a way to edit some file in scalix to use the sendmail.cf to handle the internal delivery. In that sendmail.cf file there is already the smarthost set.

[kanderson]

Perhaps the issue here is a misunderstanding of how email will work with Scalix. This will be a gross simplification, but it'll still work.

We all know how POP works. You pull mail from a POP server on port 110 and send to an SMTP on (generally) port 25.

MAPI is different. The connection only happens over port 5729, and it is a persistent connection, meaning that it doesn't "check" every 5 mins. You know IMMEDIATELY when mail arrives, and sending also happens immediately when you click send.

Because the sending port isn't 25, it isn't making an SMTP connection. MAPI speaks directly to the router which will simply deliver he message to the user without ever seeing an SMTP conversation. That is MUCH more efficient, so it allows the server to scale better. For this reason, Scalix will not pass MAPI messages to an smtp server unless they are destined for a different server, in which case, they are dropped out to sendmail.

In short, a MAPI client will NEVER speak SMTP to a Scalix/Exchange/Notes/Groupwise server. That's by design, and it can't be "fixed", because a "fix" would mean a far greater load on the server, and much worse performance.

So, if you can let us know WHY you want to drop out the messages, perhaps there is another solution that would meet your needs. I'd guess you want to log the messages, in which case you should use auditing. Or perhaps you want to keep a copy for HR to snoop through. That's archiving. Scalix does an excellent job of both.

Kev.

Kev.

[jaime.pinto]

I'd say the issue here is the one of MIGRATION, better yet, GRADUAL MIGRATION.

It seems to me scalix developers came this far and never considered that a number of organizations don't just drop their existing mail infrastructure and switch to scalix overnight. They seem to expect that we would just change the MX entries of the domain to the scalix server, create equivalent accounts for all users and deal with the exceptions by forwarding them to the "old" server and deal with all kinds of unknowns subjecting the whole organization to this uncertainty. Hardly fair to your clients.

If you have 5-10 users that is not an issue. If you have 30-50 users you have to think really hard on when to make the switch and how. If you have 100+ users it would be insane to do any kind of migration without taking a lot of things into consideration. It would be irresponsible to completely trust scalix with your organization without taking steps to fall back on something really solid and familiar to you and your users in case something goes wrong. That is our situation.

I need to provide that assurance to our managers. I also need to deal with the logistics and the schedule of configuring a large number of accounts and computers with the new scalix setting without loss of productivity or annoying our users with bugs or differences on how things work, even if very little.

To summarize, how efficient or not it may be for scalix to handle emails internally is not a concern to us. I can always get a "super computer" overnight that will very easily handle that. In fact I'm not all that interested on understanding how things work in details. I just need to provide MAPI driven group features to start with (shared calendar, contacts, tasks, notes). Email is secondary on the part of scalix at this time, since we already have an excellent IMAP server(s) in place. I would not be surprised if a large number of potential scalix adopters fall under this category.

What I need from scalix is a strategy to allow us to migrate selected users under very controlled conditions on the early stages, so that we have time to get familiar with the new features or lack of them, as well as developing the trust we need to deploy a complete migration. We also need scalix to NOT create problems for us during this transition.

Here are some examples of problems to us.
1) Not being able to make scalix take a very "humble" position in our organization in the early stages.
2) Not being able to control this conflict between domain name on the existing server and scalix, what the email for each user should be from the SAC interface regardless or the domain name or the name of the host machine, and how this information will show or be accessed from the calendar and/or contacts menus.
3) Not being able to manage this forwarding between the primary server and scalix users on an elegant way. I want to keep
4) Not being able to manage the backup and recovery of individual users mailboxes from within the SAC interface.

Maybe we could create a "MIGRATION" category on this forum, so that we could help each other more easily specifically on this subject. We probably have a lot of good information on this spread on other locations.

Thanks for your attention.
Jaime

[Kris]

I've almost finished the migration project within our company (150 Outlook users). Our old e-mail solution was a simple POP-based one. Because of the big .pst files the users have, migrating overnight was not an option.

What I did was this:

- Created all accounts that existed on the old system on the scalix system
- For all accounts on the scalix system, I created a redirect to user@temp1.domain.com. Scalix then sends this e-mail to our e-mail gateway (a Postfix machine). This machine sends all e-mail for the @temp1.domain.com to our old POP server. This server strips off the temp1 part, creating a user@domain.com address again and it will be delivered locally.
- Then I started migrating users. For every user I migrate, I remove the redirect rule on Scalix and add a redirect rule on the POP server (user@temp2.domain.com). All messages for @temp2.domain.com goes to the scalixserver, temp2 is stripped from the address and the mail is delivered to Scalix.

This way, I was able to migrate users over a long period of time (It took me almost 3 months, actually ), and everything just continued to work as people are used to.
I have to admit that it is a lot of work this way, but I didn't find another way to do this.

Hope this helps

[erikw_nl]

Hi,

A very interesting thread. I couldn't agree more with Jamie on the arguments for using a central mail hub. Another argument is the case when user workstations can not be controlled well, they may contain viruses etc. In the central mailhub, infected messages would be sorted out.

Question to Kris:
How are these redirects made on the scalix server ?.

Thx in advance.

Erik

[Kris]

On the scalix server, you can make the redirects using the "sxaa" script. This script can be found in the Admin Resource Kit.

You can then add a redirect like this:
sxaa --user <username> --redirect username@somewhere.com

Kris

[fraserm]

Jamie: Good to hear you got it worked out. It sounds like your smart host issue relates that you want to archive all mail using your existing infrastructure. Have you looked into what your going to do when all users are on Scalix?

Erik: You don't have to have a centralized mail hub to control virii. We have 5 servers geographically seperated that each contain a mailnode. ClamAV runs on each one of these. A little more work having 5 but versus having a single point of failure, or in virii land, a single point of contamination.

[kanderson]

Ok. This we can certainly help with.

For Virus scanning, Antivirus can run on each machine individually and scan at the Service Router. This will mean that every message crossing the server will be scanned. The docs for setting this up are in the knowledgebase. This link may or may not work.
http://portal.knowledgebase.net/utility ... ?rid=30972

For migration, how many users do you have, and what is your current mail solution?

Kev.

[jaime.pinto]

GOOD NEWS!!!!

Thanks everyone for your suggestions and pointers. You gave me the inspiration to make a breakthrouth.

Below is a very elegant trick, all using tools within SAC. Looking back now I suspect it may have never been intended to be used this way by the guys at scalix, but it's doing a beautiful job, just like I wanted.

1) Very important: only one domain on the scalix server: "scalixserver.domain.com"
-> do not add "domain.com" in scalix, since this may be a canonical name for the primary server "oldserver.domain.com", as well as the primary MX entry in the DNS server


2) all scalix users have 2 entries: one as a Premium (or Standard User) and another as an *Internet User*

The typical format of a Premium looks like this:
"First Last" <first.last@scalixserver.domain.com>
"First Last" <userID@scalixserver.domain.com>

The typical format of an Internet looks like this:
"First Last" <first.last@domain.com>
"First Last" <userID@domain.com>


3) For all Premium users go to Contact info and click off [ ] Display in address book, and for the internet users be sure those are all checked.
This will ensure that only the "proper" email address is displayed to each users on the System Directory, therefore keeping scalix users to send email to the "wrong" address on user@scalixserver.domain.com


4) We *only* have to worry about the actual users in the scalix server, and we don't have to do absolutely anything with the settings of users on the original mail server. We just have to put a .forward in the account that have already been migrated to the scalix with the following:
user
user@scalixserver


5) HOW DOES IT WORK?
i) Emails from the "outside"sent to any user@domain.com account will remain on the original server. For the scalix users a copy will be forwarded to the scalix server.
ii) Emails sent from scalix users (of the form user@scalixserver.domain.com) to the outside will be delivered directly (SMART_HOST no longer needed under this setup), but MASQUERADE envelope and localdomain.localhost as "domain.com" should enabled on the scalixserver sendmail.mc, so therecipients will see the normal user@domain.com on their From-Reply-TO
iii) and most importantly, emails from scalix users send to "other scalix users" as well as non scalix users under the format "user@domain.com" (that you can now see from the pulldown menu on the systems contacts) will be delivered directly to the main server, since scalix doesn't see itself as the "owner" of the "domain.com" domain. For those scalix users with a .forward on the main server a copy will return to the scalix server and delivered to user@scalixserver.domain.com, without any looping problem.


THIS IS THE BEST COMPROMISE YET!
The nice thing is that the DNS MX change pointing from the old server to the new scalix server will now be the last thing in the sequence of events, not the first anymore. That completely takes the onus and the worries of having to make sure the scalix server is working 100% from the begining.

The last step is to just add domain.com as the primary domain on the scalix server the day (or night) of the MX change, and delete all the *internet users* that are already "doubled" as premium users, something that can be done very quickly (not even 20 minutes for 50 users) and the migration is complete.



Here is the only hole in the process as I see during the transition period:
... how could I make the calendar of the "real" premium users (user@scalixserver.domain.com) show up side by side from SWA or outlook, if the display address book if turned off for all of them? The "fake" users under user@domain.com show up on the addressbook, but they are internet users, therefore don't have a calendar account? Well, in the big scheme of things this seems like a small problem now.

Again thanks for all the hints, and I hope this will be of help for some of the new scalix adopters out there, as well as the ones on a trial basis.

Jaime

[kanderson]

So lets make this one step better.

Go to a Premium user, and add an alias for that user. So that rather than

--------------------------------
The typical format of a Premium looks like this:
"First Last" <first.last@scalixserver.domain.com>
"First Last" <userID@scalixserver.domain.com>

The typical format of an Internet looks like this:
"First Last" <first.last@domain.com>
"First Last" <userID@domain.com>
------------------------------
You end up with

"First Last" <first.last@scalixserver.domain.com>
"First Last" <userID@scalixserver.domain.com>
"First Last" <first.last@domain.com>

Then move the bottom address to the top.

"First Last" <first.last@domain.com>
"First Last" <first.last@scalixserver.domain.com>
"First Last" <userID@scalixserver.domain.com>

This will cause all outbound email to go out as first.last@domain.com.
Then rather than Masqing the address, use smarthost and point at the old server.

In your case, remove all users who haven't been migrated yet from the Scalix server, as well as all of the Internet Mail users.
This will mean that a single user entry on the Scalix server will send email as the correct address. The only users who exist on Scalix will be the migrated ones.

The situation then will be:

Inbound email to a Scalix user will be recieved on the old server and forwarded to the new server as you've found.
Inbound email to an unmigrated user won't change.

Email between two Scalix users will stay on the Scalix server.
Email between two unmigrated users will never hit Scalix.

Outbound email frm an umingrated user will continue as normal.
Outbound email from a Scalix user will go through the old server and out as normal from there.

After completion of the migration, you can just point at the new scalix server rather than the old box, and remove the smarthost. Removing the first.last@scalixserver.domain.com aliases can be done at your convienience because they won't impact operations at all, and won't be used for anything.

Kev.