If an email is stuck in the queue, there would be a reason for it. The simple solution would be to determine why the email didn't leave.
As Jeff mentioned, sometimes the same domain is used, but for cases other than that, I've seen many trivial issues like non-resolving hostnames, reverse IP lookups on the server IP not working, IPs being in a blacklist, exim binaries segfaulting... etc.. Once the cause is found/fixed, then it shouldn't be an issue.
The one valid point for having DA send via smtp is this:
i need to disable sendmail
So, to accomplish that, yes, DA would need to send via smtp. DA itself does call /usr/sbin/sendmail for the case that exim was swapped for something else (I've never seen it). The catch is that DA calls /usr/sbin/sendmail as many different non-root Users (diradmin, usernames, etc).. so it can't be chowned/chmod in a specific way to make it only accessible to DA.
One simple solution for that would be if we simply add a variable for /usr/sbin/sendmail, so you can change it to something else.. like /usr/sbin/myscresetsendmail.... but will have it linked to exim. Ultimately, that wouldn't prevent it from being used, since /usr/sbin/exim still has the +suid, and your clients would only need to update their scripts to point to the new link (if they find it)
Beyond that, the solution would be for us to implement smtp in DA. I'd be very hesitant to do that though, since for the level of work involved to have DA politely learn SMTP... or just use something like a
wrapper for
nbsmtp, which is essentially what we'd end up re-coding.
As luck would have it, I've coded DA to have all email deliveries send through 1 function call, so whatever decision is made, we'd only need to implement it once.
Right now, my opinion is that /usr/sbin/sendmail is a requirement for DA to run... but if there is enough demand, other options like nbsmtp can be looked at.
John
