Re: [exim] authenticate * not work

On 5/18/05 9:30 PM, "G W" <gilbert.debian@???> wrote:

Notes (up here instead of later, although added last):
1. you need to test through the firewall to be sure about PIX SMTP fixup.
2. you need to provide an authentication method which your client supports.



> from the result above, how do i know that Cisco SMTP fixup is running?
> actually, there're 3 mail servers behind this firewall (Sendmail,
> qmail, and EXIM), the 1st 2 both are able to authenticate clients
> before relaying.

This part shows that Cisco PIX SMTP fixup is not running for this
connection. That stuff only comes out for ESMTP, not for SMTP, which the
PIX fix up forces.

SMTP>> 250-mail3.techsoft.com.hk Hello yckun202214.netvigator.com
[219.76.52.214]
250-SIZE 5242880
250-PIPELINING
250-AUTH PLAIN CRAM-MD5
250 HELP

Did this connection go through the PIX? (An earlier message pretty clearly
showed that PIX SMTP fixup was on.)

>
> Dunno if EXIM implements the same EHLO mechanism as the other 2??
If the others follow the RFCs (and they do) it does.

250-AUTH PLAIN CRAM-MD5

Do I remember that the client MUA in your tests is Microsoft Outlook or
Outlook Express? If so, you need to advertise AUTH LOGIN, too. (As usual,
Microsoft "improves" on published standards.) Meaning you need to introduce
another authenticator for AUTH LOGIN. It's almost the same, and discussed
in the Exim spec.

This area of the output:
250-AUTH PLAIN CRAM-MD5
250 HELP
SMTP<< MAIL FROM: <gilbert@???>
SMTP>> 250 OK

shows that the client didn't try to authenticate (authentication comes
between the end of the extensions list and the MAIL FROM: command) which
would explain why the authenticated = * test failed.

Or, you could compile with SPA support and write an authenticator for that.
SPA is what Microsoft does instead of CRAM-MD5 (or CRAM-anything else).
Also discussed in the spec.


From here, I can't check on whether PIX SMTP fixup is on or not:

telnet 219.76.52.214 25
Trying 219.76.52.214...
telnet: connect to address 219.76.52.214: No route to host
telnet: Unable to connect to remote host

That result was from my desktop machine...
From one of our outbound mail servers I get
telnet 219.76.52.214 25
Trying 219.76.52.214...
telnet: connect to address 219.76.52.214: Connection timed out

(Probably we're firewalled there because you aren't ready yet for the world,
which is fine.)

--John