Recently, a customer broadcasted tons of emails for her marketing campaign. All of us were affected. Urgent emails are queued along with the marketing emails (which are of lower priority).
We received complains from other customers on the same hosted environment. That's bad for business. We need to resolve this issue!
We re-looked at the MTA architecture.
The bottle-neck is at tcp_local channel. This is where emails get routed out to the Internet. We need to create a dedicated channel for the Broadcasting Application. It happens that this application is hosted with us in a standalone machine with a dedicated IP address.
Hmm... this makes our job easier.. In fact, the MTA architecture diagram already gives us a hint. It has a dedicated channel tcp_sesta channel that handles mails to be delivered to sesta.com domain.
We only need to change the requirement slightly. It's fairly simple. We want a dedicated channel tcp_bc that accepts mails from a fixed internal IP address that can deliver emails to the Internet, without affecting tcp_local channel.
Here's what we did:
mappings
Define a new mapping for the Broadcasting Application IP address in mappings.
BC_IPw.x.y.z $Y* $N
imta.cnf
Add new rewrite rule in Domain Rewrite Rules section.
!$* $F$E$U%$H@tcp_bc-daemon$Mtcp_bc
Add new mapping lookup for internal IP addresses.
! tcp_intranet! Do mapping lookup for internal IP addresses[] $E$R${BC_IP,$L}$U%[$L]@tcp_bc-daemon[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon
Define a new channel tcp_bc
(It's actually cut-and-paste-and-modify from tcp_local)
! tcp_bc-daemontcp_bc smtp mx single_sys remotehost inner switchchannel identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0 loopchecktcp_bc-daemon
Once done,
bash-3.00# /opt/sun/comms/messaging/sbin/imsimta cnbuildbash-3.00# /opt/sun/comms/messaging/sbin/imsimta restart job_controllerbash-3.00# /opt/sun/comms/messaging/sbin/imsimta restart dispatcher
No comments:
Post a Comment