seb...@gmail.com wrote, On 9/30/10 2:24 PM:
On Thu, Sep 30, 2010 at 2:42 AM, Emmanuel Lacour
<elac...@easter-eggs.com> wrote:
On Tue, Sep 28, 2010 at 03:25:11PM -0300, seb...@gmail.com wrote:
Hi Folks,
Is there any way we could use our external qmail server to handle RT
outgoing emails, instead of the default internal sendmailpipe?
If so, setup details will be appreciated.
From RT_Config.pm
C<$MailCommand> defines which method RT will use to try to send mail.
We know that 'sendmailpipe' works fairly well. If 'sendmailpipe'
doesn't work well for you, try 'sendmail'. Other options are 'smtp'
or 'qmail'.
I saw that line, but were to but the SMTP IP, account details, etc.-?
Remember we are on 3.6.10
so you can use smtp. THought, it can be less reliable if your smtp
server went unavailable. Also, as you propably set up your RT on an Unix
box, this is very recommended to have a small smtp sendmail compatible
on it to handle system emails. So why not use it for you're outgoing
emails and set your qmail as a relayhost for this smtp?
We prefer to have smtp centralized.
You may want to think about this more carefully.
Sendmail and drop-in replacements for it like Postfix are not solely or even
primarily SMTP servers, they provide a multi-function email subsystem. That
spares applications (such as RT) from a need to implement a robust mail
handling subsystem of their own, and means that if you have the local mail
submission and outbound routing parts of Sendmail (or its replacement)
configured correctly, all of your applications can send mail in a consistent
and robust way without having to implement their own SMTP client or
queue/retry infrastructure. Sendmail (or any proper replacement for it) can
easily be configured to only accept mail via local submission paths (i.e.
the sendmail binary and/or network daemons listening only on the loopback
address) and to route all mail through a centralized 'hub' system. The
alternative of having each application on each system configured to talk
SMTP directly to the central hub means you have to maintain SMTP
configurations for each application and your central hub needs to
accommodate the limitations and idiosyncrasies of each application's SMTP
client implementation. By having applications submit mail to the local mail
service (i.e. port 25 or 587 on localhost or a sendmail executable) you
isolate the applications' mail weaknesses to the host where they each run
and get a single well-behaved and robust SMTP client implementation talking
to your SMTP hub. With security tools available on some systems you can even
enforce restrictions to block anything other than the shared mail subsystem
(i.e. sendmail) from making outbound SMTP connections.
RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year -- Learn how to get the most out of RT!
