In a few days we’ll be upgrading from RT 4.0.0 to 4.2. I was reviewing the
upgrade document and I came across something distressing…
The C option for L<RT_Config/$MailCommand>, along with the associated
C<$SMTPServer>, C<$SMTPFrom>, and C<$SMTPDebug> options, has been removed
because it did not guarantee delivery. Instead, use a local MTA for
outgoing mail, via the ‘sendmailpipe’ setting to C<$MailCommand>.
I rely on those settings to send mail out to our smtp server, and thus far
it’s worked out great. In fact, they’re very resistant to the idea of
having the RT server operate as a mail server. If I’m reading this right,
am I to understand that after the upgrade I’ll no longer be able to send
mail out via an external smtp server? Is there any way around that?
In a few days we’ll be upgrading from RT 4.0.0 to 4.2. I was reviewing the upgrade document and I came across something distressing…
The C option for L<RT_Config/$MailCommand>, along with the associated
C<$SMTPServer>, C<$SMTPFrom>, and C<$SMTPDebug> options, has been removed
because it did not guarantee delivery. Instead, use a local MTA for
outgoing mail, via the ‘sendmailpipe’ setting to C<$MailCommand>.
I rely on those settings to send mail out to our smtp server, and thus far it’s worked out great. In fact, they’re very resistant to the idea of having the RT server operate as a mail server. If I’m reading this right, am I to understand that after the upgrade I’ll no longer be able to send mail out via an external smtp server? Is there any way around that?
If I’m reading this right, am I to understand that after the upgrade
I’ll no longer be able to send mail out via an external smtp server?
Is there any way around that?
The “smtp” setting could cause silent mail loss. Specifically, because
it attempts to deliver immediately, and only once, if the outgoing mail
server is unavailable at the moment RT attempts to send mail, that mail
would be dropped. The “smtp” option also did not support all of the
core mail-sending features that the “sendmailpipe” method allows.
The correct solution is to install a local MTA, which can be configured
to relay the mail to the original SMTP host. This provides a durable
mail spool in case the remote SMTP server is inaccessible. The local
MTA does not need to be configured to accept mail locally if that is not
how you wish RT to operate.
If I’m reading this right, am I to understand that after the upgrade
I’ll no longer be able to send mail out via an external smtp server?
Is there any way around that?
The “smtp” setting could cause silent mail loss. Specifically, because
it attempts to deliver immediately, and only once, if the outgoing mail
server is unavailable at the moment RT attempts to send mail, that mail
would be dropped. The “smtp” option also did not support all of the
core mail-sending features that the “sendmailpipe” method allows.
The correct solution is to install a local MTA, which can be configured
to relay the mail to the original SMTP host. This provides a durable
mail spool in case the remote SMTP server is inaccessible. The local
MTA does not need to be configured to accept mail locally if that is not
how you wish RT to operate.
Alex
To go a bit further with this, look into nullmailer. It’s a simple MTA
for machines that should be able to send mail via an SMTP host, but should not receive mail.