I'm having a problem getting SMTP AUTH to work correctly. I was
testing this with my mobile device, and the debugging output below
shows that I actually authenticated, but it refused to relay for me
still. I'm puzzled as to what the problem could be. One clue is the
error "IP name possibly forged" - but I don't see that as a fatal
error if I've already authenticated.

Any pointers would be appreciated. This applies to Sendmail-8.13.x.


Thanks.


02250 >>> 220 All ESMTP connections logged
02250 <<< EHLO [10.XXX.XXX.165]
02250 >>> 250-domain.com Hello mobile-032-XXX-
XXX-097.myoverpricedphone.net [32.XXX.XXX.97] (may be forged), pleased
to meet you
02250 >>> 250-ENHANCEDSTATUSCODES
02250 >>> 250-PIPELINING
02250 >>> 250-8BITMIME
02250 >>> 250-SIZE XXXXXX
02250 >>> 250-AUTH CRAM-MD5 DIGEST-MD5
02250 >>> 250-STARTTLS
02250 >>> 250-DELIVERBY
02250 >>> 250
02250 <<< STARTTLS
02250 >>> 220 2.0.0 Ready to start TLS
02250 <<< EHLO [10.XXX.XXX.165]
02250 >>> 250-domain.com Hello mobile-032-XXX-
XXX-097.myoverpricedphone.net [32.XXX.XXX.97] (may be forged), pleased
to meet you
02250 >>> 250-ENHANCEDSTATUSCODES
02250 >>> 250-PIPELINING
02250 >>> 250-8BITMIME
02250 >>> 250-SIZE XXXXXXX
02250 >>> 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5
02250 >>> 250-DELIVERBY
02250 >>> 250
02250 <<< AUTH PLAIN Ablahlblahblahblahblahblahblahblah==
02250 >>> 235 2.0.0 OK Authenticated
02250 <<< MAIL FROM:<me@domain.com>
02250 >>> 250 2.1.0 <me@domain.com>... Sender ok
02250 <<< RCPT TO:<me@gmail.com>
02250 >>> 550 5.7.1 <me@gmail.com>... Relaying denied. IP name
possibly forged [32.XXX.XXX.97]
02250 <<< DATA
02250 >>> 503 5.0.0 Need RCPT (recipient)
02250 <<< QUIT
02250 >>> 221 2.0.0 domain.com closing connection

In article <b0045598-7089-45bb-a383-0bcab1c1125a@x30g2000hsd.googlegroups.com>,
forrie@gmail.com <forrie@gmail.com> wrote:
>I'm having a problem getting SMTP AUTH to work correctly. I was
>testing this with my mobile device, and the debugging output below
>shows that I actually authenticated, but it refused to relay for me
>still. I'm puzzled as to what the problem could be. One clue is the
>error "IP name possibly forged" - but I don't see that as a fatal
>error if I've already authenticated.

Perhaps the serving sendmail doesn't have PLAIN listed as a
trusted authentication mechanism? (See "TRUST_AUTH_MECH".)
Also check the server's "confAUTH_OPTIONS" flags:

# a - Provides protection from active attacks during auth exchange
# y - Does not permit anonymous mechanisms
# d - Does not permit vulnerable (LOGIN, PLAIN) mechanisms
# p - Does not permit vulnerable (LOGIN, PLAIN) mechanisms unless TLS
# A - Fixes broken MTAs; needed only if using sendmail as SMTP auth client

If it includes a 'd', then PLAIN is no-go for relaying.

Rob

"forrie@gmail.com" <forrie@gmail.com> wrote:

> I'm having a problem getting SMTP AUTH to work correctly. I was
> testing this with my mobile device, and the debugging output below
> shows that I actually authenticated, but it refused to relay for me
> still. I'm puzzled as to what the problem could be. One clue is the
> error "IP name possibly forged" - but I don't see that as a fatal
> error if I've already authenticated.
>
> Any pointers would be appreciated. This applies to Sendmail-8.13.x.
>
>
> Thanks.
>
>
> 02250 >>> 220 All ESMTP connections logged
> 02250 <<< EHLO [10.XXX.XXX.165]
> 02250 >>> 250-domain.com Hello mobile-032-XXX-
> XXX-097.myoverpricedphone.net [32.XXX.XXX.97] (may be forged), pleased
> to meet you
> 02250 >>> 250-ENHANCEDSTATUSCODES
> 02250 >>> 250-PIPELINING
> 02250 >>> 250-8BITMIME
> 02250 >>> 250-SIZE XXXXXX
> 02250 >>> 250-AUTH CRAM-MD5 DIGEST-MD5
> 02250 >>> 250-STARTTLS
> 02250 >>> 250-DELIVERBY
> 02250 >>> 250
> 02250 <<< STARTTLS
> 02250 >>> 220 2.0.0 Ready to start TLS
> 02250 <<< EHLO [10.XXX.XXX.165]
> 02250 >>> 250-domain.com Hello mobile-032-XXX-
> XXX-097.myoverpricedphone.net [32.XXX.XXX.97] (may be forged), pleased
> to meet you
> 02250 >>> 250-ENHANCEDSTATUSCODES
> 02250 >>> 250-PIPELINING
> 02250 >>> 250-8BITMIME
> 02250 >>> 250-SIZE XXXXXXX
> 02250 >>> 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5
> 02250 >>> 250-DELIVERBY
> 02250 >>> 250
> 02250 <<< AUTH PLAIN Ablahlblahblahblahblahblahblahblah==
> 02250 >>> 235 2.0.0 OK Authenticated
> 02250 <<< MAIL FROM:<me@domain.com>
> 02250 >>> 250 2.1.0 <me@domain.com>... Sender ok
> 02250 <<< RCPT TO:<me@gmail.com>
> 02250 >>> 550 5.7.1 <me@gmail.com>... Relaying denied. IP name
> possibly forged [32.XXX.XXX.97]
> 02250 <<< DATA
> 02250 >>> 503 5.0.0 Need RCPT (recipient)
> 02250 <<< QUIT
> 02250 >>> 221 2.0.0 domain.com closing connection

Have you included PLAIN in TRUST_AUTH_MECH() ?
What is reported by the command below?
echo '$={TrustAuthMech}' | sendmail -bt

URL(s):
http://www.sendmail.org/tips/
* SMTP AUTH § (external link)
http://www.sendmail.org/~ca/email/auth.html

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
The difference between art and science is that science is what we
understand well enough to explain to a computer. Art is everything else.
-- Donald Knuth, "Discover"

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.


Thanks.

Here is the output:

# echo '$={TrustAuthMech}' | sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> >

It's also a blank value when I enter it manually in -bt mode.


Thanks.

"forrie@gmail.com" <forrie@gmail.com> wrote:

> Here is the output:
>
> # echo '$={TrustAuthMech}' | sendmail -bt
> ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
> Enter <ruleset> <address>
>> >
>
> It's also a blank value when I enter it manually in -bt mode.

The most likely explanation:
sendmail.cf file has been generated by previous version of sendmail.mc.

Sendmail reads sendmail.cf, sendmail.mc is a "human friendly" file used
to generated sendmail.cf.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
If you think education is expensive, try ignorance.
-- Derek Bok, president of Harvard

I used the current files supplied by the FreeBSD sendmail port, which
is up-to-date for 8.14.2.


##### $Id: cfhead.m4,v 8.116 2004/01/28 22:02:22 ca Exp $ #####
##### $Id: cf.m4,v 8.32 1999/02/07 07:26:14 gshapiro Exp $ #####

These are standard.

A grep through the resulting sendmail.cf shows:

# are group-writable :include: and .forward files (un)trustworthy?
# True (the default) means they are not trustworthy.
# Trusted user for file ownership and starting the daemon
#O TrustedUser=root
# Trusted users #
#Ft/etc/mail/trusted-users
R$* $| $={TrustAuthMech} $# RELAY
### trust_auth: is user trusted to authenticate as someone else?
SLocal_trust_auth
Strust_auth
R$* $| $* $: $1 $| $>"Local_trust_auth" $2

The rules appear to be there.

I wonder if my declaration of the AUTH rules is in the correct portion
of the sendmail.mc file. I tried a couple of locations and it didn't
make a difference. Obviously, they show up in the SMTP connection
dialog for EHLO.


Thanks.

On Mar 7, 8:37 pm, res@keevey.(none) (Rob Stampfli) wrote:
> In article <any5u87...@Dale.fsf.hobby-site.com>,
> Andrzej Adam Filip <a...@onet.eu> wrote:
>
> >"for...@gmail.com" <for...@gmail.com> wrote:
>
> >> 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.
>
> >Could you post results produced by the test command below:
> > echo '$={TrustAuthMech}' | sendmail -bt
>
> I would think you would want to see this output from the server
> sendmail -- the sendmail on the other end -- not forrie's client
> sendmail.
>
> Rob

I'm not sure I follow you. The debugging output is from the MX server
itself. The forwarding was attempted from my properly configured
mobile device. It authenticated successfully, but sendmail is still
not allowing the relay.

On Mar 8, 3:46 am, "for...@gmail.com" <for...@gmail.com> wrote:
> On Mar 7, 8:37 pm, res@keevey.(none) (Rob Stampfli) wrote:
>

> I'm not sure I follow you. The debugging output is from the MX server
> itself. The forwarding was attempted from my properly configured
> mobile device. It authenticated successfully, but sendmail is still
> not allowing the relay.

Could the reason be (IP name possibly forged [32.XXX.XXX.97] ) some
other antispam rule kicking in despite authentication? (a missing
delay_checks comes to mind). Just a thought.

Cheers,
alf

On Mar 8, 7:21 am, alf <alessandro.forghi...@gmail.com> wrote:
> On Mar 8, 3:46 am, "for...@gmail.com" <for...@gmail.com> wrote:
>
> > On Mar 7, 8:37 pm, res@keevey.(none) (Rob Stampfli) wrote:
>
> > I'm not sure I follow you. The debugging output is from the MX server
> > itself. The forwarding was attempted from my properly configured
> > mobile device. It authenticated successfully, but sendmail is still
> > not allowing the relay.
>
> Could the reason be (IP name possibly forged [32.XXX.XXX.97] ) some
> other antispam rule kicking in despite authentication? (a missing
> delay_checks comes to mind). Just a thought.
>
> Cheers,
> alf

Hi Alf,

Thanks for your reply.

I do not have delay_checks in there - and I read through the README to
try and find out what it does. I don't see how it would affect AUTH,
though I liked the ruleset for the bad_helo (which requires it). Most
of my rejections are access and RBL based, so I like them dealt with
upon connection. The README didn't feel clear about delay_checks vs.
not.


Thanks.

In article
<01e7efbc-f5eb-4988-a93c-3dd6e372b717@k2g2000hse.googlegroups.com>
"forrie@gmail.com" <forrie@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
per@hedeland.org

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

I commented out the redefinition of TRUST_AUTH_MECH which made no
difference.

In article
<085dede3-8b49-4a52-a16d-06b0b46ba9b3@e31g2000hse.googlegroups.com>
"forrie@gmail.com" <forrie@gmail.com> writes:
>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.
>>
>
>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.

I sure don't know - what gave you the idea that you should define it?
It's already defined for you in cf/m4/cfhead.m4.

> 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')

No need (and apparently no ) to quote the exact same passage again.
Are you really unable to see the difference between

TRUST_AUTH_MECH(`KERBEROS_V4 DIGEST-MD5')

and

define(`TRUST_AUTH_MECH', `KERBEROS_V4 DIGEST-MD5')

? The former is the correct usage, the latter is broken. (The fact that
it also breaks subsequent correct usage of TRUST_AUTH_MECH() isn't
important since you don't try that.)

>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.

Yes, that you should use

TRUST_AUTH_MECH(`LOGIN PLAIN CRAM-MD5 DIGEST-MD5')dnl

>Where does delay_checks come in to play here.

Nowhere.

--Per Hedeland
per@hedeland.org

On Mar 9, 8:23 am, p...@hedeland.org (Per Hedeland) wrote:
> In article
> <085dede3-8b49-4a52-a16d-06b0b46ba...@e31g2000hse.googlegroups.com>
>
>
>
> "for...@gmail.com" <for...@gmail.com> writes:
> >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.
>
> >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.
>
> I sure don't know - what gave you the idea that you should define it?
> It's already defined for you in cf/m4/cfhead.m4.
>
> > 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')
>
> No need (and apparently no ) to quote the exact same passage again.
> Are you really unable to see the difference between
>
> TRUST_AUTH_MECH(`KERBEROS_V4 DIGEST-MD5')
>
> and
>
> define(`TRUST_AUTH_MECH', `KERBEROS_V4 DIGEST-MD5')
>
> ? The former is the correct usage, the latter is broken. (The fact that
> it also breaks subsequent correct usage of TRUST_AUTH_MECH() isn't
> important since you don't try that.)
>
> >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.
>
> Yes, that you should use
>
> TRUST_AUTH_MECH(`LOGIN PLAIN CRAM-MD5 DIGEST-MD5')dnl
>
> >Where does delay_checks come in to play here.
>
> Nowhere.
>
> --Per Hedeland
> p...@hedeland.org

Hi Per,

You're right - I wasn't seeing the difference between define and just
use of the MACRO. It's been a while since I've tweaked the MC file
and I just never saw this detail. Ooops.

It works now, thank you for your , I appreciate it.


_F