l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
September 2: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2002 Jun 01 11:37

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Change mail host, lose e-mails?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Change mail host, lose e-mails?



On Fri, 31 May 2002, Mark K. Kim wrote:
> I can certainly recommend that we keep the current mail service running
> for the next month or two after switching over.  But getting everyone to
> keep checking their new and old mails for weeks is going to be a problem.

Depending upon how mail is implemented for users, and who provides the
actual mail service, you have multiple options.

> We do have the ability to forward the mails on our current mail service,
> but forwarding mails using IP addresses isn't going to work.  Is there
> another way to forward the e-mails?  (I can, of course, forward mails to
> my alternate e-mail addresses, but not everyone here has alternate e-mail
> addresses.  And of course the ones with only company e-mail address are
> the ones that are least savvy with computers and will forget to check
> both e-mail accounts... :P)

If people just check their mail in a shell, and you have two different
physical hosts, names can be altered on the two mail servers such that the
old server has a "static route" (application layer, mail server
setting) for how to deal with mail to the "old domain mail handler" which
can include specification of the new server by IP and/or name (with an
/etc/hosts entry). This could allow all old mail to automagically be
forwarded from the old server (if it should ever happen to be delivered
there by misake) to be sent to the new server anyway. You would still need
to migrate over all old mail messages mbox-es to the new server, but that
would be a one time task.

I know I can configure my mail server to be a mail host relay for another
ail server - accept mail for delivery, where my server will say to the
other mail server, "yes I will deliver this message for you" and then
consult my mail server's static handling to see that all mail for this
domain should be forwarded to another mail server at another IP address
(static routing at application layer). This is much the same as for backup
mail servers. 

If only IMAP is used, then, your fix is much like that for the shell users
above - except, you mus be certain the client side IMAP server name
actually picks up the NEW IP address with a DNS and not use an old cached
IP address beyond the DNS served content "life-span". A failure or
fall-back to the old IP address would mean odd clients might try t consult
the old server (by IP) for mail.

If only POP is used, then you may have a number of pop clients to
re-configure, but mail forwarding for new messages may work. HOWEVER, some
pop mail clients (mostly in windows and mac land) have a tendancy to
assume too much for you and make different local accounts and storage
boxes for each popmail server/pickup. You also may have the same problem
as above with the IMAP and stale DNS lookup data.

Both of the problems with stale DNS lookup data seem very uncommon (from
experience) with client machines when compared to the odd ISPs DNS. More
common (but still uncommon) is a problem when users use the lmhosts.sam or
the /etc/hosts or the macs equiv local hosts file (sorry - cant remember
what it is for Mac OS 6.x-9.x) for static IP assignments with host names
(consulted before DNS by default.)

Of course, I am sure there are other mail clients / MTA combos, and there
are likely other solutions with these in mind too. But, it starts
with a short "lifetime" for all your DNS settings. Make sure the new
"lifespan" for your host lookups are sync-ed over all of your "slave" DNS
from your "master" and the changes that are sync-ed actually take effect.
Then test your clients to make sure they will use the new settings. Try to
time the modification to the NSI/VeriSign/(Your Registrar Company) to
happen over the weekend, or over days when nobody is working and then try
to make the transition finish before Sunday. With a 1 day expiration on
lookup requests, and one day for most root domain changes for
authoritative domain DNS, 2 days can easily be sucked up by one weekend
and afford you time starting Monday to turn your focus away from the
servers and instead to the clients.

-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.