Hi everyone

Having gotten no answer on my messages and digging deeper into sendmail
I found one possible reason why a client authentication is not done.

Looking at the code in deliver.c

/* if other server supports authentication let's authenticate */
if (mci->mci_state != MCIS_CLOSED &&
mci->mci_saslcap != NULL &&
!DONE_AUTH(mci->mci_flags) && !iscltflgset(e, D_NOAUTH))

I found that, in my case, the D_NOAUTH flag is set in the envelope which
appears to inhibit authentication in this case.

Does anyone have a hint where to look for this flag.

Thanks

Erich

More findings in the sendmail code...

mega wrote:
> Hi everyone
>
> Having gotten no answer on my messages and digging deeper into sendmail
> I found one possible reason why a client authentication is not done.
>
> Looking at the code in deliver.c
>
> /* if other server supports authentication let's authenticate */
> if (mci->mci_state != MCIS_CLOSED &&
> mci->mci_saslcap != NULL &&
> !DONE_AUTH(mci->mci_flags) && !iscltflgset(e, D_NOAUTH))
>
> I found that, in my case, the D_NOAUTH flag is set in the envelope which
> appears to inhibit authentication in this case.
>
> Does anyone have a hint where to look for this flag.

I found that the mailer_con_info structure in the deliver code gets
overwritten and the original D_NOAUTH flag is lost. My assumption is
that at this point there will be no more client authentication. Can
anyone familiar with the sendmail code please confirm these findings?

In any case, I can see my postings to the list, did not get any reply
though. There must be someone sufficiently knowledgeable about the
sendmail code to at least tell me if I am on the right track at all.

Thanks for replies

Erich

In article <45ba086f$0$18821$5402220f@news.sunrise.ch> mega
<erich.titl@think.ch> writes:
>More findings in the sendmail code...
>
>mega wrote:
>> Hi everyone
>>
>> Having gotten no answer on my messages and digging deeper into sendmail
>> I found one possible reason why a client authentication is not done.
>>
>> Looking at the code in deliver.c
>>
>> /* if other server supports authentication let's authenticate */
>> if (mci->mci_state != MCIS_CLOSED &&
>> mci->mci_saslcap != NULL &&
>> !DONE_AUTH(mci->mci_flags) && !iscltflgset(e, D_NOAUTH))
>>
>> I found that, in my case, the D_NOAUTH flag is set in the envelope which
>> appears to inhibit authentication in this case.
>>
>> Does anyone have a hint where to look for this flag.

The iscltflgset() function checks for the flag being set in the
${client_flags} macro - for some reason this macro is undocumented, but
you can find where it is initialized from the ClientPortOptions Modifier
(M=...) field in daemon.c. The effect of including 'A' in this field is
documented in doc/op/op.*:

A don't use AUTH when sending e-mail

So I guess that either you have this set, or you have some rules that
modify the ${client_flags} macro (not very likely).

>I found that the mailer_con_info structure in the deliver code gets
>overwritten and the original D_NOAUTH flag is lost. My assumption is
>that at this point there will be no more client authentication. Can
>anyone familiar with the sendmail code please confirm these findings?

No, I'm afraid you're confused here - the mci structures are in a
dynamically allocated chunk of memory, there is one for each "active"
host/connection. They may of course be modified over time, and if a
connection goes away, the corresponding mci structure may be reused for
another connection (see mci.c) - but this doesn't cause any loss of
information that "should" have been kept around, and in any case this is
not where the D_NOAUTH flag is, see above. The DONE_AUTH() test in the
code above is of course due to the fact that even if there are multiple
messages being sent to a given host in a given connection,
authentication only happens once.

>In any case, I can see my postings to the list, did not get any reply
>though. There must be someone sufficiently knowledgeable about the
>sendmail code to at least tell me if I am on the right track at all.

I don't think so, but check your ClientPortOptions settings, if any.
And since you unwisely started a new thread in the middle of your
reports, I can't find the original part of your track...

--Per Hedeland
per@hedeland.org

Per

Per Hedeland schrieb:
> In article <45ba086f$0$18821$5402220f@news.sunrise.ch> mega
> <erich.titl@think.ch> writes:
....

>
>> In any case, I can see my postings to the list, did not get any reply
>> though. There must be someone sufficiently knowledgeable about the
>> sendmail code to at least tell me if I am on the right track at all.
>
> I don't think so, but check your ClientPortOptions settings, if any.
> And since you unwisely started a new thread in the middle of your
> reports, I can't find the original part of your track...

Sorry for that deviation, I must have panicked.

In any case I looked now at my ClientPortOptions and found 'AS' as
modifiers. I do not recall why they were there, this is a .mc file which
dates back a long time.

Nevertheless, I removed the relevant modifiers and now authentication works.

Sorry, everybody for all the extra noise. Thanks to point me to the
right direction.

Erich