On Thu, 2004-10-28 at 15:43, Paul Howarth wrote:On Thu, 2004-10-28 at 03:02, Ow Mun Heng wrote:
However, to answer your original question, I have my MSP send mail out via my MSA, not my MTA, and this is how I do it:
Why do you need to have AUTH?? Your Relay provides AUTH is it? (or I
gather it's your own MTA somewhere) Lookin at the headers, it's
goalkeeper.
I defined my MSA as follows: DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
The "a" mailer flag enforces authentication before the MSA will accept mail. This stops spammers or viruses from using the submission port for delivery of local mail, bypassing milters and other spam checks etc. A result of that is that any client (including the MSP) that wants to send mail through the MSA must authenticate first. Both the MTA and MSA support AUTH.
GoalKeeper is TLS Enabled, and thus encrypted, but after it reaches mx1.redhat.com, it becomes plaintext. (correct?)
sendmail will use TLS if it is available (and configured). Delivery will resort to plain text at any point that doesn't support TLS.
dnl Use the MSA with AUTH define(`RELAY_MAILER_ARGS', `TCP $h 587')
What's $h? Hostname? port 587? That's the definition of the MSA right?
This is telling the MSP to relay mail out using the MSA instead of the MTA, i.e. connect to port 587 of the destination host $h (always the same host for the MSP, usually localhost) instead of port 25.
5. Add to sendmail.mc:
LOCAL_RULESETS SLocal_trust_auth R$* $: $&{auth_authen} Rsmmsp $# OK
What about this in the sendmail-cf docs? Other things don't work well with the MSP and require tweaking or workarounds. For example, to allow for client authentication it is not just sufficient to provide a client certificate and the corresponding key, but it is also necessary to make the key group (smmsp) readable and tell sendmail not to complain about that, i.e.,
define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile')
Additionally the MTA must trust this authentication data so the AUTH= part will be relayed on to the next hop
The Local_trust_auth ruleset above is the bit that causes MTA to trust the authentication data from the MSP.
You only need define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile') if you're doing TLS (i.e. with certificates). Regular SMTP AUTH doesn't need certificates.
Now.. The question is, does it retain it's TLS/encrypted state after leaving the MSA or MTA? on to the next mail hop?
Only if the next hop supports it. Some do, most don't.
Paul.
