Just curious by why Exim vs PostFix? Is it like the whole emacs vs vi debate, or are there capability, security or performance reasons for choosing one over the other? I'm not married to any as long as it sends mail like it's supposed to and doesn't whore itself out to spammers :)
On Thu, Jan 16, 2014 at 12:32 AM, Dan Egli <ddavide...@gmail.com> wrote: > On January 14, 2014, S. Dale Morrey wrote: > > > > > You are correct. I changed it and that worked. > > Glad to hear it. :) > > > > > Now oddly enough I'm not receiving any email on the domain. DNS Tools is > > > showing I now have no MX record set. My registrar on the otherhand shows > > > it as being set correctly. This is true even after a logout, clearing my > > > cookies and cache, rebooting the computer, etc. Something is clearly > stuck > > > on their end and I'm working with support to resolve it. > > > > Sounds like a corrupted DNS record somehow. Probably the issue is that it > hasn't expired from your DNS SERVER yet. Clearing your cache and rebooting > only clears the local cache. The next time you request the domain it goes > directly to the indicated name server and asks for the records. If the > records are incorrect, but haven't passed the TTL, then you'll get the same > info back and caching name server won't ask for other info. If I was you, > I'd try using dig to determine where the records are wrong. i.e., > > $ dig mx mydomain.com > > will ask the local nameserver that you use, and > > $ dig mx mydomain.com @<hosting provider's DNS svr> > > will specifically ask the hosting provider's DNS server for the > information. Dig can really be your friend in this time. Once you > determine if it's just Amazon's DNS cache (you did say this was on an AWS > node, right?) that is goofed, or is a fault of your provider's DNS you can > take steps to correct it. Easiest step that I know if is to simply update > the serial number (assuming a BIND style nameserver and not something else) > of the domain on the hosting provider's DNS server. Once the serial # is > increased (or extremely decreased, i.e. going from 2014011001 to 1) then > subsequent queries by other DNS servers (once the TTL value has been > reached anyway) will (or should) automatically re-grab the domain zone > information, including MX records. Naturally your hosting provider has to > do this, but I'd think they'd be willing to try something so simple to see > if it helps fix the records. Also find out how long their TTL is in the > zone record. I've seen some providers that set like a one week TTL, and > frankly I find that a bad idea unless you're SURE everything works > correctly (which it obviously doesn't) and nothing is going to change > within that week. One week expire, sure. But I'd recommend no more than six > to twelve hours of TTL on a development stage server/record. > > > > Meanwhile, one thing you could consider is forcing postfix to deliver mail > for mydomain.com to a specific server rather than relying on mx dns > queries. This is often referred to as a smart host (especially in sendmail > logic). I don't have any idea HOW to do this in postfix. I said before I'm > an EXIM person myself. But I would be shocked if it wasn't possible. Then > you wouldn't have to worry about DNS MX problems on you end. Now, of > course, others would be unable to email you except from the site, but it's > a step in the right direction anyway. > > > > Good luck! > > > --- Dan > > > On Tue, Jan 14, 2014 at 12:59 PM, S. Dale Morrey <sdalemor...@gmail.com > >wrote: > > > You're correct. I changed it and that worked. > > Now oddly enough I'm not recieving any email on the domain. DNS Tools is > > showing I now have no MX record set. My registrar on the otherhand shows > > it as being set correctly. This is true even after a logout, clearing my > > cookies and cache, rebooting the computer etc. Something is clearly > stuck > > on their end and I'm working with support to resolve it. > > > > These problems are unrelated since the DNS records are with the > registrar. > > Still it's an odd coincidence. > > FYI I did have my MX records set to the hosted email provider I mentioned > > earlier. > > > > Just, odd :( > > > > > > On Tue, Jan 14, 2014 at 12:25 AM, Dan Egli <ddavide...@gmail.com> wrote: > > > > > On Sunday, Jan 12, 2013, S. Dale Morrey wrote: > > > > > > > No it's just supposed to send from the website. The destination is > the > > > > > > > hosted provider I mentioned earlier. > > > > > > > > > > > > I think others will have mentioned this one too, but from what I can > > read, > > > Postfix is trying to deliver mydomain.com to the local system, which > is > > > the > > > problem. Somehow Postfix has determined that it's an authorized mail > end > > > point for mydomain.com. So it receives a message for > > > <anyone>@mydomain.comand accepts it, then tries to look up the user so > > > it knows where to > > > actually write the message to disk. But these users don't exist on the > > > server, so it bounces the messages instead. > > > > > > > > > > > > I don't know where to tell you to look since I always use Exim as my > MTA, > > > but somewhere in the Postfix config is a list of domains that it is > > > configured to accept mail for. You want to make sure mydomain.com is > NOT > > > in > > > that list. If you want to contact me off list, I'd be happy to help you > > > plug in Exim instead. Then I can guide you through any problems, and > show > > > you some tricks to help diagnose these issues yourself. :) > > > > > > > > > > > > I suspect what you did is set this up thinking that you needed to > > configure > > > Postfix to allow messages for mydomain.com to be processed since they > > are > > > being generated by the Drupal instance on that server. But that's not > > quite > > > correct. Again, I don't know how to separate the two in Postfix, being > a > > > long time Exim user myself. But what you need to do is configure your > > > server so that it knows nothing about mydomain.com, but does accept > mail > > > from localhost (127.0.0.1), or possibly from the IP address of that AWS > > > instance. That is the best way I can think of. > > > > > > > > > > > > Good luck! > > > > > > --- Dan > > > > > > > > > On Tue, Jan 14, 2014 at 3:41 AM, Kyle Waters <u...@unum5.org> wrote: > > > > > > > On 01/12/2014 09:43 PM, S. Dale Morrey wrote: > > > > > > > >> No it's just supposed to send from the website. The destination is > > the > > > >> hosted provider I mentioned earlier. > > > >> > > > >> > > > > > > > > I ran into this in reverse recently. I'm hosting the email and the > > > > website is hosted by the people who developed it. They were trying > to > > > send > > > > an email to the people who the site is for and kept getting their > mail > > > sent > > > > back to them, since their server didn't have those usernames. I was > > > > contacted because they thought it was an error on my side with my > > server > > > > bouncing the emails back. So at least you realized it was your > > > > configuration and you didn't contact the admin of the proper email > > > server :) > > > > > > > > Kyle > > > > > > > > > > > > /* > > > > PLUG: http://plug.org, #utah on irc.freenode.net > > > > Unsubscribe: http://plug.org/mailman/options/plug > > > > Don't fear the penguin. > > > > */ > > > > > > > > > > /* > > > PLUG: http://plug.org, #utah on irc.freenode.net > > > Unsubscribe: http://plug.org/mailman/options/plug > > > Don't fear the penguin. > > > */ > > > > > > > /* > > PLUG: http://plug.org, #utah on irc.freenode.net > > Unsubscribe: http://plug.org/mailman/options/plug > > Don't fear the penguin. > > */ > > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
