On Tue, 5 Dec 2006, Jo Rhett wrote:
> René Berber wrote:
> > It's the same one I posted before:
> >
> > Received: from MARISELA (dsl-189-149-70-163.prod-infinitum.com.mx
> > [189.149.70.163] (may be forged))
> > (authenticated bits=0)
> > by mail.legosoft.com.mx (8.13.8/8.13.8) with ESMTP id kB3G26P6019032
> > for <[EMAIL PROTECTED]>; Sun, 3 Dec 2006 10:02:16 -0600 (CST)
> >
> > The original test is looking for a pair of closing parenthesis ")]" or "])"
> > which is not there (not together, but a fixed IP probably has those), or
> > something followed by colon and there is no colon at all (the test is done
> > starting with "from").
>
> Do you know why the SMTP authenticating server was forging the HELO
> name? Normal mail clients will give their IP address, right? And the
> "may be forged" only appears if they gave a full name and resolution
> succeeded *and* none of the addresses returned matched the helo name.
>
> In short, this may have been a deliberate choice to prevent a match on
> hosts with forged helo names. It would make sense.
Jo you are mistaken. Sendmail adds the "(may be forged)" comment when
the client's IP rDNS and DNS don't match, it has -nothing- to do with the
HELO name.
It still should not matter. So long as the client can authenticate to
the server's statisfaction, SA should honor its decision regardless of
how bogus the HELO or client's DNS entrys look.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
