Authenticated outbound email?

Question

I'm wondering if there's a way to configure Messaging Server 7.0 to authenticate on outbound SMTP connections. Specifically, there are services that allow email relay, but only if the inbound connection is authenticated.
To be clear, I'm talking about an MTA to MTA transfer. It appears you can configure some MTAs to log into a mail relay before passing mail along.
As an example, sendmail accepts this in sendmail.mc
FEATURE(authinfo, `hash -o /etc/mail/authinfo')
define(`SMART_HOST', `outbound.mailhop.org')
I've gone through a lot of material, but I can't find any hint that Messaging server allows this. I'm I missing something, or is it just not a supported feature.
Thanks,
John

Answer 1

jandrusiak wrote:
I'm wondering if there's a way to configure Messaging Server 7.0 to authenticate on outbound SMTP connections. Specifically, there are services that allow email relay, but only if the inbound connection is authenticated.
To be clear, I'm talking about an MTA to MTA transfer. It appears you can configure some MTAs to log into a mail relay before passing mail along.
I've gone through a lot of material, but I can't find any hint that Messaging server allows this. I'm I missing something, or is it just not a supported feature.The functionality was added to Messaging Server 7.0 update 1 (Communication Suite 6 update 1) but it appears to have not been (publicly) documented.
<snip>
Limited SASL capabilities have been added to the SMTP client. SASL authentication will be attempted if the maysaslclient or mustsaslclient channel options are set (it must succeed if mustsaslclient is set).
The PLAIN and EXTERNAL SASL mechanisms are currently supported. The AUTH_USERNAME and AUTH_PASSWORD TCP channel options provide the credentials for the plain mechanism and the EXTERNAL_IDENTITY TCP channel option provides the identity string for SASL EXTERNAL. (EXTERNAL_IDENTITY can be set to the empty string to enable SASL EXTERNAL without an identity string.)
</snip>
So to give you an example that worked in my own MS7.0 update 1 test environment:
1. Create a new channel which uses the mustsaslclient keyword in imta.cnf e.g.
! tcp_secure
tcp_secure nomx multiple subdirs 20 dequeue_removeroute maxjobs 7 musttlsclient mustsaslclient pool SMTP_POOL daemon [192.168.1.10]
tcp_secure-daemonNote: the musttlsclient keyword ensures that the connection is encrypted prior to passing across the plain-text username/password. Also in this case the channel is configured to send emails to a dedicated system with an IP address of 192.168.1.10.
2. Create a rewrite rule which directs emails for [email protected] to the new channel:
domain.com $U%$D@tcp_secure-daemon3. Create a tcp_secure_option channel option configuration file which contains the SASL auth username/password:
bash-3.00# cat /opt/sun/comms/messaging/config/tcp_secure_option
AUTH_USERNAME=authuser
AUTH_PASSWORD=secretpassword4. Rebuild the MTA configuration and restart e.g.
./imsimta cnbuild;./imsimta restart5. Send an email to [email protected], you should see something like the following in the logs:
27-Jan-2009 12:25:51.82 tcp_secure                DEQS 1 [email protected] rfc822;[email protected]
[email protected] [192.168.1.10] dns;[192.168.1.10] (TCP|1.2.3.4|34682|192.168.1.10|25) (domain.com --
Server ESMTP [Sun Java System Messaging Server 6.2-9.14 [built Aug 19 2008]]) smtp;250 2.1.5 address accepted for
deferred processing: [email protected]: DEQS stands for "(D)equeue, (E)SMTP, TL(S)/SSL used". Q appears to be the new code for SASL client auth (also not yet documented).
Regards,
Shane.