Re: Email migration and MX records
No one realistically has a choice about dealing with either for email. In any case, we found a vastly simpler way of doing this; our cloud email security/anti-spam provider (Barracuda) can spool mail for delivery if our systems go offline for up to 96 hours, so we’re setting them to not deliver tonight, doing the migration, changing our MX Records after to let the outside know where its supposed to send us email and then changing the delivery address we have on Barracuda to the new one, and the mail should flow in. In theory! :-) Thanks for all the suggestions, everyone. On Jan 6, 2023, at 12:52 PM, Mark Andrews mailto:ma...@isc.org>> wrote: Just a reason to not use them for your email. Not everybody is in a position to repair stuff on a 7/24/365 basis. Notify that the mail is delayed by don’t bounce. -- Mark Andrews On 7 Jan 2023, at 06:11, Brown, William mailto:wbr...@e1b.org>> wrote: Last I saw, both M365 and Google only retry for 24 hours before returning as undeliverable. -- William Brown WNYRIC/Erie 1 BOCES -Original Message- From: bind-users mailto:bind-users-boun...@lists.isc.org>> On Behalf Of Marcus Kool Sent: Wednesday, January 4, 2023 7:17 AM To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> Subject: Re: Email migration and MX records This email originated from outside of the organization. Use caution when replying, opening attachment(s), and/or clicking on URL's. SMTP is a wonderful protocol that queues messages and retries delivery for 5 days so a non-responsive email server is no issue. Just do not have a temporary solution that bounces emails since those will never arrive (the sender is notified about the bounce). Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Email migration and MX records
Just a reason to not use them for your email. Not everybody is in a position to repair stuff on a 7/24/365 basis. Notify that the mail is delayed by don’t bounce. -- Mark Andrews > On 7 Jan 2023, at 06:11, Brown, William wrote: > > Last I saw, both M365 and Google only retry for 24 hours before returning as > undeliverable. > > > -- > William Brown > WNYRIC/Erie 1 BOCES > > -Original Message- > From: bind-users On Behalf Of Marcus Kool > Sent: Wednesday, January 4, 2023 7:17 AM > To: bind-users@lists.isc.org > Subject: Re: Email migration and MX records > > This email originated from outside of the organization. Use caution > when replying, opening attachment(s), and/or clicking on URL's. > > > SMTP is a wonderful protocol that queues messages and retries delivery for 5 > days so a non-responsive email server is no issue. > Just do not have a temporary solution that bounces emails since those will > never arrive (the sender is notified about the bounce). > > Confidentiality Notice: This electronic message and any attachments may > contain confidential or privileged information, and is intended only for the > individual or entity identified above as the addressee. If you are not the > addressee (or the employee or agent responsible to deliver it to the > addressee), or if this message has been addressed to you in error, you are > hereby notified that you may not copy, forward, disclose or use any part of > this message or any attachments. Please notify the sender immediately by > return e-mail or telephone and delete this message from your system. > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Email migration and MX records
Last I saw, both M365 and Google only retry for 24 hours before returning as undeliverable. -- William Brown WNYRIC/Erie 1 BOCES -Original Message- From: bind-users On Behalf Of Marcus Kool Sent: Wednesday, January 4, 2023 7:17 AM To: bind-users@lists.isc.org Subject: Re: Email migration and MX records This email originated from outside of the organization. Use caution when replying, opening attachment(s), and/or clicking on URL's. SMTP is a wonderful protocol that queues messages and retries delivery for 5 days so a non-responsive email server is no issue. Just do not have a temporary solution that bounces emails since those will never arrive (the sender is notified about the bounce). Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Email migration and MX records
Bruce Johnson via bind-users wrote:- >Were making an O365 tenant switchover for our domain (a subdomain of the >arizona.edu domain) and moving from our Barracuda cloud email SMTP to the >Universitys tenant, but email cannot flow until the Arizona.edu O365 tenant >can take over our email domain. This is probably more of an email than a DNS question. In any event, I have reasonably regularly undertaken such moves for clients. You are correct that the email often cannot be setup on the system until it is removed from the old. Trying to achieve this with a simple MX change WILL result in some email being rejected/bounced. >In anticipation I set our TTL for MX records quite low before the break (150 >seconds) so, but the process may take up to an hour (if everything goes well ) Sensible... >Will setting our mx record to a bogus address cause email to bounce on the >sending end and eventually get retried later after the mx record has been >properly set to the Universities main smtp MX address? Depending on what you mean by "bogus", this approach has the scope to end badly. It might work, but it might not. Furthermore, you will not know whether is did work or not. Indeed, different senders may produce different results. An approach which should cause queuing (which I do not recommend) would be to have a hostname & IP as the MX, which is under your control and which does NOT have an SMTP server running. >Or are we approaching this in the wrong way? Basically our end result is we >want to stop accepting email from anywhere until the whole process has been >changed and we have established the correct route so email starts flowing >correctly. You have correctly identified "we want to stop accepting email from anywhere until the whole process has been changed". My approach, as has been suggested by others, is to have a temporary email server as an intermediate MX (ie only ONE MX server), which has a hard delivery rule to the real OLD mail server. In order for this to work, the old and new mail servers have to be configured not to do any DNS based processing on messages from the temporary server; specifically not SPF or DNSBL. Just before the migration, configure the server not to deliver the email but hold it in a queue. When the work is complete and tested, configure the temporary server to deliver email to the new mail destination. Once dequeued and everything is working, change the DNS MX to point to the new destination. After TTL expiry (plus a bit), remove the temporary config re SPF etc from the new server. Doing this fairly often, I keep a temporary server for the purpose, in my case a fairly simple Postfix configuration. This also allows one to see all the logs and (if one wishes) take copies of emails in transit to assist with troubleshooting or for resubmission. >As its been explained to me the main campus tenant cannot start accepting >email for our domain until weve transferred the email domain between >tenants, so we cannot just change the MX record in our DNS server to the >Universitys (a Cisco Ironport setup) This sounds plausible. Hope this helps. -- Best wishes, Matthew -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Email migration and MX records
Bruce, I would push back and ask for more information from whomever is leading you down that path as it does not sound right to me although others more familiar with DNS magic might have better suggestions to DNS changes. But if Barracuda is just a front-end for email that does antivirus/spam filtering I would expect you could update Barracuda to send email to your new M365 tenant when it is ready without any DNS change to your MX record. Once that change was made you could then update MX records to bypass the Barracuda service altogether. Keep in mind that you may specify a short TTL, but you may see emails for DAYS after the change from my experience when we changed our MX servers years ago. If you received information that you could not use a third party device in front of M365, you received incorrect information. You can definitely use another service in front of M365 although the additional cost might not pencil out. We let the third party store dangerous/nasty emails in their quarantine and forward SPAM/Bulk over to M365 Junk Email folders so employees have one space to look for those things. > > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > Bruce Johnson via bind-users > Sent: Tuesday, January 3, 2023 3:32 PM > To: bind-users@lists.isc.org > Subject: Email migration and MX records > > We?re making an O365 tenant switchover for our domain (a subdomain of the > arizona.edu domain) and moving from our Barracuda cloud email SMTP to the > University?s tenant, but email cannot flow until the Arizona.edu O365 > tenant can take over our email domain. > > In anticipation I set our TTL for MX records quite low before the break > (150 seconds) so, but the process may take up to an hour (if everything > goes well ) > > Will setting our mx record to a bogus address cause email to bounce on the > sending end and eventually get retried later after the mx record has been > properly set to the Universities main smtp MX address? > > Or are we approaching this in the wrong way? Basically our end result is > we want to stop accepting email from anywhere until the whole process has > been changed and we have established the correct route so email starts > flowing correctly. > > As it?s been explained to me the main campus tenant cannot start accepting > email for our domain until we?ve transferred the email domain between > tenants, so we cannot just change the MX record in our DNS server to the > University?s (a Cisco Ironport setup) > > > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Email migration and MX records
SMTP is a wonderful protocol that queues messages and retries delivery for 5 days so a non-responsive email server is no issue. Just do not have a temporary solution that bounces emails since those will never arrive (the sender is notified about the bounce). Marcus On 03/01/2023 21:31, Bruce Johnson via bind-users wrote: We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup) -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Email migration and MX records
Hi Bruce, It would be better to have an SMTP server return 421 "4.3.0" or 421 "4.7.0" while the migration is under way instead of bouncing the connection. 421 will tell all SMTP servers everywhere to "try again later". The 421 error is a proven greylisting configuration. Not knowing what is all involved with the actual migration, another option might be something as simple as putting the prod Barracuda server(s) into "maintenance mode". If that will prevent the migration from happening perhaps Barracuda can spin up an SMTP server that only answers with 421. Or, if you all are able, you could roll your own SMTP server to answer 421. Obviously standard do-not-test-in-prod, don’t wing it and hope for the best .. have a step-by-step playbook disclaimers apply and there is nothing wrong with a lower TTL of 60 seconds or less to facilitate reverting. John -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bruce Johnson via bind-users Sent: Tuesday, January 3, 2023 3:32 PM To: bind-users@lists.isc.org Subject: Email migration and MX records We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup) -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Email migration and MX records
Hi Bruce, This is something I'm presently battling with as well. My current previously tested plan is: 1. Create all user accounts (with NEW email addresses) on the new email system 2. Setup a temporary forwarder on an existing *temporary* email server (we use hMail) which forwards all email sent to the *current* address to the *new temporary* address 4. Pre-stage the DNS zone file with the new DNS provider (we use Google Cloud DNS which allows this) 5. Transfer the domain name by *purchasing* a transfer/renewal with Google DNS - this allows us to immediately specify the Google Cloud DNS zone file thus preventing downtime 6. At a later date: migrate the destination domain to the new tenant This allows you to transfer the domain to a new tenant whilst still forwarding interim emails whilst you jump through the domain validation hoops. I am, of course, welcome to any recommended improvements to this process. Otherwise, good luck! Best, Richard. -Original Message- From: bind-users On Behalf Of Bruce Johnson via bind-users Sent: 03 January 2023 9:32 pm To: bind-users@lists.isc.org Subject: Email migration and MX records We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup) -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Email migration and MX records
We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup) -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
