Todd, your thoughts are always welcome, so keep them coming. Regarding the 8+ hours, I'll get the exact details for you. Can you provide me with all the info (domain, mailboxes, etc.) off-list so I can look into this. I 100% agree that this is not acceptable.
The policy itself is certainly not ideal and there are options we're looking at currently. One option that we're working on right now is that all mail would be treated as non-local mail. This would eliminate most of the issues that I noted. I'd be interested in any other thoughts you or anyone has too. -----Original Message----- From: Todd Jagger [mailto:[EMAIL PROTECTED] Sent: Monday, March 01, 2004 11:06 AM To: Bruce Dorland Cc: [EMAIL PROTECTED] Subject: Re: saturday email product question Good Monday, Bruce Dorland wrote: > First off the MX record check runs every 20 minutes, not every hour (we > reduced this time to help facilitate migrations/setup/etc.). It is run at > :00, :20 and :40. I just validated this with my dev folks to make sure it > was behaving as expected. Not to quibble, but then please explain why some 8+ hours after the Tucows specified MX record *was* the only MX record, and the verification script showed everything was happy, the domain I was working with was not activated. I made sure the record was the only one at 1PM Saturday, and the domain was not actually online until sometime between midnight and 9am Sunday. It seems to me a conversation with one of the support people one time revealed that if there's a validation failure in checking the MX the interval for checking is increased? Can you verify that no matter what the validation script runs every 20 mins until it gets a positive response? > Also, we do require that the Tucows specified MX > record is the only MX record. The reason why we perform this MX record check > is to validate that the person who purchased email for the domain actually > has control of the domain. If we simply went ahead and setup a domain in our > email system without this validation, the email address would: > > a) be able to send mail locally to anyone even though they potentially had > no control or right to the domain and > b) any mail addressed to this domain from another email address on the local > system would not reach the intended destination as it would attempt a local > delivery. > There's gotta be a better way to make this work better for both Tucows and our customers. I could be wrong but it would appear the consensus is that this policy is not ideal on a number of levels. I'm sure I, and others here, would be glad to toss some ideas around that would make everything smoother and meet Tucows's needs as well. > Regarding migrations, there is of course the chance that mail sent to a > mailbox that has had the MX record changed to point to Tucows, but has yet > to have the mailbox setup in our email system will receive mail within the > 20 minute timeframe and this mail would be rejected. This does make timing > of any migrations important (e.g., non-high traffic email hours are best). Of course this assumes the 20 minute timeframe is absolute... 20 mins is no problem. 8+ hours is. > I'd recommend coordinating any migrations that you're concerned about with > our sales folks as it's always worth having a discussion before hand to make > sure it goes smoothly. If necessary, we will work with you to bypass the MX > check in certain circumstances to ensure that no mail is lost. For larger > migrations, we can also help with mailbox setup, etc. > That's great and I appreciate it very much. Unfortunately, this case didn't allow me to take advantage of that courtesy even had I been aware of its availability. I just got a call on Friday evening from a customer frantically asking me to move her email from her local ISP. No way to talk to anyone at Tucows over the weekend. Remember Bruce, my criticisms are intended to be constructive and hopefully this dialog will help us to identify things that might be done better with input from your customers - we resellers - to benefit our customers, who ultimately pay the bill. And isn't that what this is all about? Thanks very much, Todd Jagger
