[rt-users] SMTP for email

[Bill Cole]

sebsua at gmail.com wrote, On 9/30/10 2:24 PM:
> On Thu, Sep 30, 2010 at 2:42 AM, Emmanuel Lacour
> <elacour at easter-eggs.com>  wrote:
>> On Tue, Sep 28, 2010 at 03:25:11PM -0300, sebsua at 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.