local mail delivery priority

jmstacey

Verified User
Joined
Feb 12, 2004
Messages
3,880
Location
Colorado
I recently had a very curious problem. A user was not recieving the activation email after signing up for an account. I finally narrowed it down and discovered that it was because the user had used the same domain to signup with as was in his current email address. So exim was trying to deliver the mail locally instead of sending it out to the real address. And of course since that mailbox did not exist the email dies with an error.

So I was wondering if it is possible and what configurations needed to be changed to have the server first try to deliver locally and if it fails, try to send it out into the internet, and if it again fails, finally return the mail to the sender with the error?
If this is possible and advisable, perhaps this configuration could be added/modified to/in the stock configuration file.
 
Last edited:
jmstacey said:
I recently had a very curious problem. A user was not recieving the activation email after signing up for an account. I finally narrowed it down and discovered that it was because the user had used the same domain to signup with as was in his current email address. So exim was trying to deliver the mail locally instead of sending it out to the real address. And of course since that mailbox did not exist the email dies with an error.

So I was wondering if it is possible and what configurations needed to be changed to have the server first try to deliver locally and if it fails, try to send it out into the internet, and if it again fails, finally return the mail to the sender with the error?
If this is possible and advisable, perhaps this configuration could be added/modified to/in the stock configuration file.

We'll the mailsoftware will use the DNS (Bind) on the server to check where the domain is. So deleting the entry from the local list will probaly not be a solution if the zone files for that domain exist locally.

But if there are no zone files, you should be able to delete the user from the local list (if there is one with exim, qmail does have it)
 
The DA exim.conf file (I wrote it) looks for local domains in in /etc/virtual/domains and for local users in various files in the /etc/virtual/example.com directory (where example.com is replaced by the domain in question).

Since DA is a compiled C program there's not much you can do to change it's behavior; I'd send a request to DA support and see how they feel about making a change.

Perhaps the simplest change (it could be implemented in a skin, but I'd rather see DA implement it) would be to disallow, at input stage, an email address at the same domain being created.

Jeff
 
Hello,

We'll, it's really not a hard check to do. If you guy's think it should be added, I can do it without any troubles..

Also, it can either be done with javascript in the skin, or in the DA binary, or both.

Let me know what you guys think, and I can make any needed changes.

John
 
Personally, I would say javascript.
But then it depends on if the check in DA is limited only to the signup process since it would be nice if users could change the email address to whatever they wanted after that initial creation.
Thats my two cents.

It doesn't really matter to me, just so that it gets done. :)
 
Last edited:
We prefer the contact address NEVER be at the domain we host.

Two reasons come to mind immediately:

1) if the server hosting client's domain is down we might still want to be able to contact client by email.

2) if the client is suspended for nonpayment or other reason we realize we have a much better chance of retaining client if we can communicate with him/her.

Others of course may feel differently.

My thoughts on where to do it:

1) it might be easier on the skin-developers if they didn't have to deal with javascript.

2) but if done in javascript it will give skin-developers more control over how to handle it, or whether to do it at all.

Jeff
 
Jon, did you ever resolve this issue?

I've been considering it all day today (I know, over a year late :cool: but late is better than never.

I can't figure out a way to do it without creating a loop.

For example, DA will try MX delivery on all incoming email. Okay, MX delivery works, so it uses it.

And gets the email again and tries it again.

Over and over again.

Were you able to overcome this?

Jeff
 
Wow, I had to reread the thread to remember what it was about :p

I never resolved it.
I actually didn't do any work beyond my original request. If I'm remembering right, I pretty sure I was asking this to be done at the mail server level (the try local then internet), so at exim. I wasn't sure if it could be done with just some configuration changes or if custom code changes within exim would be required.
To me that seems much less feasible/desirable now.

It's not an issue for me now that email addresses are stored with client information by my billing program. So I would have to make any changes for checking the email address into the program.
 
I just have the server always do a proper dns mx check, regardless if their is a local domain or not, this isnt the best solution I know but prevents mail been delivered to the wrong place.
 
Actually, if you read my post above you'll see that it can prevent mail delivery from occurring anyplace. (See my notes about the mail loop; using local delivery is the only easy way out of the loop.)

I've been corresponding with several folk on the exim-users list, and so far the only reasonable answer to make sure you get the mail delivered to a new customer is to use a different server to send the welcome email; I'm working on that now, but if it appears to be the only solution it would require intervention by JBMC staff, since it would require a change to how DA works. (And Jon would have to make similar changes to his billing program.)

I'm also looking at a method whereby exim will check DNS to see if it's the lowest cost MX record for a domain, and if so, deliver it, but otherwise pass it on to the lowest cost MX record.

I know that Sendmail does that, but I don't know if exim does or not.

However, even if it does, it doesn't resolve the issue of what's going to happen when using an outside mailwasher.

The best solution might be to not let the new client use the same domain he's typed into his domain field into his contact email address. That was recommended to me by someone on the exim list (they're really a great bunch of people), but I don't like it because I'm afraid we'd lose business if the new client didn't immediately know another email address.

More comments are solicited; we really do have to resolve this so we can keep all our business :) .

Jeff
 
The only solution I see that would be transparent to the (potential) customers would be to run your website/helpdesk/billing system on a seperate server, maybe even a virtual server or a server hosted with another company. This way the problem would not affect you unless you manually set up accounts in DA.
 
not sure what you mean about the loop I have never had a loop, here is the part of exim.conf that is changed.

lookuphost:
driver = dnslookup
# domains = ! +local_domains
ignore_target_hosts = 127.0.0.0/8
condition = "${perl{check_limits}}"
self = pass
same_domain_copy_routing = true
transport = remote_smtp
no_more
 
Having just spent a half-hour studying the differences between your lookuphost router and mine...

bold represents your additions:

Code:
lookuphost:
  driver = dnslookup
  [b]# domains = ! +local_domains[/b]
  ignore_target_hosts = 127.0.0.0/8
  condition = "${perl{check_limits}}"
  [b]self = pass[/b]
  [b]same_domain_copy_routing = true[/b]
  transport = remote_smtp
  no_more
First let's look at the line you commented out...

By commenting out the line beginning with domains you've effectively told this router to route all domains, whether or not they're local. So far so good.

By adding the line self = pass you've changed the default routing.

According to the book: exim: The Exim SMTP Mail Server, written by Philip Hazel, the author of exim:
After Exim has routed an address to a list of remote hosts, it checks to see if the first host on the list is the local host. Usually, this indicates some kind of configuration error, and by default Exim treats it as such. However there are types of configuration where this is legitimate, and for these cases the self option is used to specifiy what is to be done.
--Page 44, Section 3.10.4

So let's now look at the action specified by the pass setting for self:
If self is set to pass, the router returns "pass", which means that the address is passed to the following router
--Page 113, Section 6.5.2
Here's where it gets a bit complicated. If your DNS lookup returns your local host, then the self = pass line would simply undo your commenting out of the domains = ! +local_domains line. If your DNS lookup returns a different host (as it would if you used a different server for DNS lookups than the one you run on your local server), then this router would work as you'd expect.

So...
as long as /etc/resolv.conf doesn't list your nameserver at all, not as localhost, or by IP#), you can expect your code to work under most circumstances.

Except...
What about the circumstance where your client's domain uses something like the Junk Email Filter described here?

Under this circumstance local_domains wouldn't be checked, and the email would be routed to the lowest cost MX server, which would be the one at the filter company. They'd preprocess the email and send it back to your server. Since local_domains isn't being checked, the email would be sent back to them, creating a loop

If you haven't seen a loop, my guess is that's because you haven't seen this scenario. We have, so we understand the problem.

To complete our analysis of your lookuphost router:

Setting same_domain_copy_routing = true simply avoids duplicate DNS lookups when multiple addresses for a given email have the same domain name. (ibid., page 122)

This saves time if you're hosting mailing lists with lots of email going to the same domain, but it doesn't change the actions.

If you disagree with the points I've made, then please comment; it's not my intent to mislead. If I'm wrong, I'd like to know it.

Jeff
 
I am not an expert on exim and I take in what you say, I guess I have been lucky I have no users who are in that scenario. The problem is if I used the exim.conf shipped with DA and have it so it sends emails to local domains without doing MX lookups is I get a scenario where welcome email's fail to send out if the user's domain is to be hosted on my server and is yet to propogate over. Which did happen a few times.

If you know of a simple change that would allow the mx to always be looked up without the loop then great but I had to fix the issue I was experiencing.
 
I'm working on it; it will require some changes to DA, which I'll present to John as soon as I know they'll work.

Jeff
 
As of today, after a reply directly from Dr. Philip Hazel, who wrote exim, it appears the only way to solve the problem is to send your welcome emails from another server.

Do you use your DA server to send outgoing email from your own desktop? If so, then this is a good reason why you shouldn't.

If you use your ISP's server to send your own email you can, whenever you receive a copy of a welcome email, send the new account a short message welcoming him/her personally, and asking s/he if s/he ever got the welcome email.

If the new client responds no, you could always resend it from your own system.

A lousy workaround.

But you've got only a few options:

1) Lose the customers who disregard your warnings, and post the email address of the domain they're transferring.

2) Use your own second email server to send the welcome emails, if you have one

3) Trust a third-party company to send your welcome emails for you and send your welcome emails.

4) Send an email from your ISP's mailserver.

The two middle options, two and three, require changes to DirectAdmin.

Comments welcome.

Jeff
 
So basically the setup I moved to awhile ago (where the billing/order system is on a different server) is about as good as you can do without rejecting/warning about email addresses with the same domain? (Since DA wouldn't be sending the email)

But the problem still exists for DirectAdmin...
 
Last edited:
I actually use a DA server but not the same as the main DA server for email's but the workaround you posted is messy and not great and I would rather suffer from the potential problems you told me with my configuration then deal with what you just posted.
 
We all do what we feel is best for our servers and our systems.

My preliminary answer is to have DA call exim with a special limited exim.conf file only when sending out welcome emails.

I'm going to bring this to JBMC staff's attention now.

Jeff
 
Back
Top