Hi folks

I have posted a few messages lately concerning my inability to
authenticate on my ISP's smart host. Unfortunately noone seemed to be
inclined to answer, possibly to an insufficient problem analysis on my
side or other NO-NO's on the list.

Could please someone just briefly tell me if my set up is that weird
that it cannot possibly work with a recent sendmail version or point me
to the glitch I did. Please let me know if the information I posted
previously was insufficient or misleading.

I have 8.13.8 on a dynamically assigned address. My ISP requires SMTP
AUTH and only offers PLAIN and LOGIN. He also offers STARTTLS.

For my MUAs I require SMTP AUTH, see below

TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5')dnl
define(`confAUTH_MECHANISMS', `PLAIN DIGEST-MD5 CRAM-MD5')dnl
FEATURE(`authinfo',`hash /etc/mail/authinfo')dnl

Authenticating my remote MUAs woks fine with this set up. Relaying mail
to my ISP's smart host fails because authentication is not done, nor is
my set up trying to do starttls on that session.

I am trying to force starttls using the following in the access db.

Try_TLS:smtp.hispeed.ch OK
Try_TLS: OK

I am trying to allow/force authentication using the following in the
/etc/mail/authinfo db

AuthInfo:smtp.hispeed.ch "U:XXXXXX@hispeed.ch" "P:YYYYYY" "M:PLAIN"
AuthInfo: "U:XXXXXX@hispeed.ch" "I:XXXXXX@hispeed.ch" "P:YYYYYY"
"M:PLAIN"

Yes, I built the maps and yes, I restarted sendmail. Despite all this
neither starttls nor authentication is attempted when relaying.

Thanks for

Erich

mega unleashed the infinite monkeys on 04/02/2007 14:01 producing:
> Hi folks
>
> I have posted a few messages lately concerning my inability to
> authenticate on my ISP's smart host. Unfortunately noone seemed to be
> inclined to answer, possibly to an insufficient problem analysis on my
> side or other NO-NO's on the list.
>
> Could please someone just briefly tell me if my set up is that weird
> that it cannot possibly work with a recent sendmail version or point me
> to the glitch I did. Please let me know if the information I posted
> previously was insufficient or misleading.
>
> I have 8.13.8 on a dynamically assigned address. My ISP requires SMTP
> AUTH and only offers PLAIN and LOGIN. He also offers STARTTLS.

Have you ensured that SASL is built to support plain and login. ISTR
that these aren't compiled in by default.

--
Rob MacGregor (BOFH)

Rule 37: "There is no 'overkill'. There is only 'open fire'
and 'I need to reload.'"

Rob MacGregor schrieb:
> mega unleashed the infinite monkeys on 04/02/2007 14:01 producing:
>> Hi folks
>>
>> I have posted a few messages lately concerning my inability to
>> authenticate on my ISP's smart host. Unfortunately noone seemed to be
>> inclined to answer, possibly to an insufficient problem analysis on my
>> side or other NO-NO's on the list.
>>
>> Could please someone just briefly tell me if my set up is that weird
>> that it cannot possibly work with a recent sendmail version or point me
>> to the glitch I did. Please let me know if the information I posted
>> previously was insufficient or misleading.
>>
>> I have 8.13.8 on a dynamically assigned address. My ISP requires SMTP
>> AUTH and only offers PLAIN and LOGIN. He also offers STARTTLS.
>
> Have you ensured that SASL is built to support plain and login. ISTR
> that these aren't compiled in by default.

Mhhhh... I am using the SASL library which comes with my distro. AFAIK
it should support PLAIN. Do you have a procedure how to check? It
appears to have a plugin for the PLAIN mech.

cyrus-sasl-plain 2.1.19 cyrus-sasl plugin for the PLAIN mechanism

Thanks

Erich

Sorry for the second reply....

Rob MacGregor schrieb:
> mega unleashed the infinite monkeys on 04/02/2007 14:01 producing:
>> Hi folks
>>
>> I have posted a few messages lately concerning my inability to
>> authenticate on my ISP's smart host. Unfortunately noone seemed to be
>> inclined to answer, possibly to an insufficient problem analysis on my
>> side or other NO-NO's on the list.
>>
>> Could please someone just briefly tell me if my set up is that weird
>> that it cannot possibly work with a recent sendmail version or point me
>> to the glitch I did. Please let me know if the information I posted
>> previously was insufficient or misleading.
>>
>> I have 8.13.8 on a dynamically assigned address. My ISP requires SMTP
>> AUTH and only offers PLAIN and LOGIN. He also offers STARTTLS.
>
> Have you ensured that SASL is built to support plain and login. ISTR
> that these aren't compiled in by default.
>

-rwxr-xr-x 1 root root 679 2004-10-02 04:03 libplain.la
lrwxrwxrwx 1 root root 18 2006-04-19 00:21 libplain.so ->
libplain.so.2.0.19
lrwxrwxrwx 1 root root 18 2006-04-19 00:21 libplain.so.2 ->
libplain.so.2.0.19
-rwxr-xr-x 1 root root 16987 2004-10-02 04:03 libplain.so.2.0.19

I checked the Sendmail.conf file and found no PLAIN nor LOGIN there,
added it, but it made no difference.

Erich

Hi everyone

In my attempt to get my authentication running I reverted again to the
code. Is anyone here with enough insight into the sendmail code to give
me a few hints where to dig.

This all refers to 8.13.8

I found that in my case the D_NOTLS flag was set in the envelope at
deliver.c line 2946, thus clearing the usetls flag and possibly
inhibiting STARTTLS. Does anyone know where the offered server commands
are set in the envelope?

here the usetls flag gets reset

usetls = bitset(MCIF_TLS, mci->mci_flags);
if (usetls)
usetls = !iscltflgset(e, D_NOTLS);

The same appears to happen with the D_NOAUTH flag.

Thanks for hints for the search for the place where these flags are set.

Erich

In article <52219$45c784be$5449b38a$369@news.hispeed.ch> mega
<erich.titl@think.ch> writes:
>
>In my attempt to get my authentication running I reverted again to the
>code. Is anyone here with enough insight into the sendmail code to give
>me a few hints where to dig.

You seem to have started at least half a dozen different threads on this
subject - I don't know what you hope to achieve by that, but it
certainly doesn't make it any easier to out - nor does a meningless
Subject like the one you've chosen for this thread.

>This all refers to 8.13.8
>
>I found that in my case the D_NOTLS flag was set in the envelope at
>deliver.c line 2946, thus clearing the usetls flag and possibly
>inhibiting STARTTLS. Does anyone know where the offered server commands
>are set in the envelope?
>
>here the usetls flag gets reset
>
>usetls = bitset(MCIF_TLS, mci->mci_flags);
>if (usetls)
> usetls = !iscltflgset(e, D_NOTLS);
>
>The same appears to happen with the D_NOAUTH flag.

I answered your question about D_NOAUTH in another of your threads, the
answer for D_NOTLS is essentially the same.

--Per Hedeland
per@hedeland.org

Per

Per Hedeland schrieb:
> In article <52219$45c784be$5449b38a$369@news.hispeed.ch> mega
> <erich.titl@think.ch> writes:
>> In my attempt to get my authentication running I reverted again to the
>> code. Is anyone here with enough insight into the sendmail code to give
>> me a few hints where to dig.
>
> You seem to have started at least half a dozen different threads on this
> subject - I don't know what you hope to achieve by that, but it
> certainly doesn't make it any easier to out - nor does a meningless
> Subject like the one you've chosen for this thread.

You are right, I somehow missed the reply to my first posting, as
reported in the second.

>
>> This all refers to 8.13.8
>>
>> I found that in my case the D_NOTLS flag was set in the envelope at
>> deliver.c line 2946, thus clearing the usetls flag and possibly
>> inhibiting STARTTLS. Does anyone know where the offered server commands
>> are set in the envelope?
>>
>> here the usetls flag gets reset
>>
>> usetls = bitset(MCIF_TLS, mci->mci_flags);
>> if (usetls)
>> usetls = !iscltflgset(e, D_NOTLS);
>>
>> The same appears to happen with the D_NOAUTH flag.
>
> I answered your question about D_NOAUTH in another of your threads, the
> answer for D_NOTLS is essentially the same.

Excuse me, I must have missed that answer, I dug in the archives and
found your reply.

Sorry for the extra noise.

Erich