Sendmail Milter Question

[Paul Howarth]

Ow Mun Heng wrote:
> 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.