On Mar 8, 7:17 pm, p...@hedeland.org (Per Hedeland) wrote:
> In article
> <01e7efbc-f5eb-4988-a93c-3dd6e372b...@k2g2000hse.googlegroups.com>
>
> "for...@gmail.com" <for...@gmail.com> writes:
> >I have these in my sendmail.mc:
>
> >define(`confAUTH_OPTIONS', `A y p')dnl
> >define(`TRUST_AUTH_MECH', `LOGIN PLAIN CRAM-MD5 DIGEST-MD5')dnl
> >define(`confAUTH_MECHANISMS', `LOGIN PLAIN CRAM-MD5 DIGEST-MD5')dnl
>
> >all of the examples I followed had this or similar.
>
> You didn't try looking in the actual sendmail documentation? From
> cf/README:
>
> ----------
> Per default, relaying is allowed for any user who authenticated
> via a "trusted" mechanism, i.e., one that is defined via
> TRUST_AUTH_MECH(`list of mechanisms')
> For example:
> TRUST_AUTH_MECH(`KERBEROS_V4 DIGEST-MD5')
> ----------
>
> The only thing define(`TRUST_AUTH_MECH' ...) does is to break the
> TRUST_AUTH_MECH() macro.
>
> --Per Hedeland
> p...@hedeland.org

Actually, I did, and I find the documentation a little confusing. If
defining this macro would break something, what would the possible
purpose be for defining it outside of the .m4 configuration. The
README says:


Per default, relaying is allowed for any user who authenticated
via a "trusted" mechanism, i.e., one that is defined via
TRUST_AUTH_MECH(`list of mechanisms')
For example:
TRUST_AUTH_MECH(`KERBEROS_V4 DIGEST-MD5')

So, if I define the trusted mechanisms that I have, which are
available via SASL2, then it shouldn't break anything if they are
already available, right? Or am I missing something.

Where does delay_checks come in to play here.


Thanks,

Forrest