Bug 616181 - sendmail has suddenly stopped relaying for authenticated users
Summary: sendmail has suddenly stopped relaying for authenticated users
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: sendmail (Show other bugs)
(Show other bugs)
Version: 13
Hardware: All Linux
low
high
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-19 19:37 UTC by David A. De Graaf
Modified: 2010-08-05 17:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-04 07:35:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description David A. De Graaf 2010-07-19 19:37:40 UTC
Description of problem:  sendmail has stopped relaying for authenticated senders


Version-Release number of selected component (if applicable):
sendmail-8.14.4-4.fc13.i686

How reproducible:
Perfectly.

Steps to Reproduce:
1.  Configure sendmail to allow relaying for laptop (use previously working setup). 
2.  Send a message from laptop.
3.  Observe "Relaying denied." in  /var/log/maillog.
  
Actual results:  Relaying denied.


Expected results:  stat=Sent


Additional info:

Effective with Fedora 13 and sendmail-8.14.4-4.fc13.i686, sendmail has
stopped relaying using the LOGIN PLAIN mechanism.

I have used this method successfully for years to allow my laptops to
relay via my main gateway machine, even when using the external public
address for this machine, datix.us.  Obviously, to avoid becoming a
spam enabler, I have to restrict who may use this address to pass mail
thru to my ISP, thence to anyone.  I configure /etc/mail/sendmail.mc
on all my machines with these lines:

  define(`confAUTH_OPTIONS', `A')dnl

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

  define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5
  LOGIN PLAIN')dnl

  FEATURE(`authinfo',`hash /etc/mail/auth/client-info')dnl

and create a directory, /etc/mail/auth/ with files, client-info and
client-info.db.  These contain a userid and passwd that are used to
authenticate a prospective email to be relayed.  An external machine
can use datix.us to relay only by supplying the matching userid and
passwd when an SMTP connection is attempted.

I recently discovered that relaying was failing with /var/log/maillog
entries like this:
  Jul 16 17:04:43 datium sendmail[4378]: o6GL4h09004378:
  ruleset=check_rcpt, arg1=<degraaf_da@yahoo.com>,
  relay=host-24-246-129-31.morrisbb.com [24.246.129.31] (may be
  forged), reject=550 5.7.1 <degraaf_da@yahoo.com>... Relaying denied.
  IP name possibly forged [24.246.129.31]

which suggests that authentication had never been attempted and the
sender was evaluated as a "possibly forged" IP.


After much frustration I found a solution at
http://www.linuxforums.org/forum/servers/5206-smtp-auth-sasl-sendmail-not-getting-along.html
from someone named "oommd".  I should add a line to
/usr/lib/sasl2/Sendmail.conf to make it read:
    pwcheck_method: saslauthd
    mech_list: LOGIN PLAIN

This does indeed work, and relaying is working once again.
It's hard to imagine a more cryptic and well hidden configuration
file.

This "fix" is wrong on at least two counts:

First, /usr/lib is no place for user-configuration data, ever.
All such data must be in /etc/mail/ along with all there is to know about 
sendmail.

Second, the data is redundant.  It should not be necessary to mention
saslauthd; use of that is understood and is automatic.
It should not be necessary (it never used to be) to list mechanisms.
The one to be used is already specified in sendmail.mc.

This file should be abolished, and the system made to work without it.

Comment 1 Jaroslav Škarvada 2010-07-27 13:53:33 UTC
The FEATURE authinfo is used on clients to provide credentials which will be used during authentication to smtp server. You don't need to use it on server. For details please see: http://www.sendmail.org/~ca/email/auth.html#smtpclient

For successfull SMTP auth you need SASL2 on your server and clients, e.g. cyrus-sasl and cyrus-sasl-plain packages. You need to start saslauthd service on your server. By default it uses PAM backend for auth, but you can change it in /etc/sysconfig/saslauthd. Sendmail comes SASL2 preconfigured, you can check:

# rpm -ql sendmail | grep Sendmail.conf
/usr/lib64/sasl2/Sendmail.conf

# cat /usr/lib64/sasl2/Sendmail.conf
pwcheck_method:saslauthd

This is default settings and it should be enough. AFAIK the 'mech_list: LOGIN PLAIN' you mentioned should be mechanism used by sendmail to comunicate with saslauthd and you don't need to configure it.

Thus it seems there was something wrong with you sendmail installation, because the Sendmail.conf is installed by default. I checked this with two freshly installed Fedora 13 computers, one configured as server (private relay to ISP) and the other as roaming computer using AUTH LOGIN. In this setup everything was working as expected and out of the box.

Also please note that using LOGIN/PLAIN without SSL is security risk, especially when roaming.

You are right that /usr/lib* is not good place for config and this was also fixed in rawhide several months ago - the config was placed to /etc/sasl2/. This change will be presented in F14. But it will be not backported to F13 (it may cause problems).

BTW it looks like your DNS records are not correct. Your PTR looks OK, but it seems there is no A record for host-24-246-129-31.morrisbb.com. That's why the sendmail rejects with "IP name possibly forged" (in case the AUTH is not used). For details please see: http://www.sendmail.org/~ca/email/relayingdenied.html#RELDENFORGED

Thus for me it seems, there is nothing to fix.

Comment 2 David A. De Graaf 2010-07-29 20:21:41 UTC
Jaroslav Škarvada, thank you for your reply.

Further extensive experiments confirm my original complaint:
that relaying is now denied whereas it used to be allowed.
If and only if a line is _added_ to the default file does relaying
work.  The file /usr/lib/sasl2/Sendmail.conf must have this line
added:
    mech_list: LOGIN PLAIN

Since you say you have tested and found that relaying works without
this line, I am befuddled.  I note that your server is 64-bit.
It seems impossible, but could that explain the difference?

To clarify my test setup, I have a laptop and a server, both 32-bit,
both freshly installed Fedora 13, with all updates.
  $ rpm -qa "sendmail*" "cyrus-sasl*" | sort
  cyrus-sasl-2.1.23-11.fc13.i686
  cyrus-sasl-devel-2.1.23-11.fc13.i686
  cyrus-sasl-gssapi-2.1.23-11.fc13.i686
  cyrus-sasl-lib-2.1.23-11.fc13.i686
  cyrus-sasl-md5-2.1.23-11.fc13.i686
  cyrus-sasl-plain-2.1.23-11.fc13.i686
  sendmail-8.14.4-4.fc13.i686
  sendmail-cf-8.14.4-4.fc13.noarch
  sendmail-milter-8.14.4-4.fc13.i686

saslauthd is running on both.
/etc/mail/sendmail.mc includes these relevant lines:

Laptop:
  define(`SMART_HOST', `datix.us')dnl
  define(`confAUTH_OPTIONS', `A ')dnl
  TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
  define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
  FEATURE(`authinfo',`hash /etc/mail/auth/client-info')dnl

Server:
  define(`SMART_HOST', [mail.morrisbb.net])dnl
  define(`confAUTH_OPTIONS', `A ')dnl
  TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
  define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
  dnl FEATURE(`authinfo',`hash /etc/mail/auth/client-info')dnl

On both machines /etc/mail/auth exists:
  # ll -d /etc/mail/auth /etc/mail/auth/*
  drwx------ 2 root root  4096 Jul 18 15:07 /etc/mail/auth/
  -rw------- 1 root root   584 Jul 18 15:07 /etc/mail/auth/client-info
  -rw------- 1 root root 12288 Jul 18 15:07 /etc/mail/auth/client-info.db
but use of this data is dnl'd on the server.  The client-info file
contains a user and passwd that agrees with entries in /etc/passwd and
/etc/shadow on the server.

On the server, but not the laptop, I added the second line, which
previously was never needed:

  $ cat /usr/lib/sasl2/Sendmail.conf
  pwcheck_method:saslauthd
  mech_list: LOGIN PLAIN

With this setup, relaying works;  a message sent from the laptop to my
test account, degraaf_da@yahoo.com, is accepted for relaying at the
server, and sent onward to it's SMART_HOST, and delivered.


In arriving at this working setup, I tested lots of alternatives
because the instructions in sendmail.mc are anything but clear, at
least to me.  In particular, the default confAUTH_OPTIONS are `A p'
and the comments say:
dnl # The following allows relaying if the user authenticates, and disallows
dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links

which suggests that leaving the `A p' might be a good thing.
Also where, or if, the /etc/mail/auth data is required was unclear.

Therefore, I took an empirical approach and tested all combinations
of options `A p' vs `A' and absence or presence of /etc/mail/auth on
both the laptop and server to determine which combinations yield a
successful relay.

Without presenting the full table of results here, the conclusions are

1 - The confAUTH_OPTIONS must be `A'.  Presence of `p' on either
machine causes relaying to be denied.

2 - The auth data must be present on the laptop, but its presence or
absence on the server is immaterial.  This proves that the
authorization is against the standard Linux login userid and passwd
and suggests that it would be a good idea to define a special login
account with a difficult passwd and no shell just for this purpose.
This strategy seems obvious, but I've never seen it recommended.

Finally, with the working setup described above, I removed the extra
line from /usr/lib/sasl2/Sendmail.conf
  mech_list: LOGIN PLAIN
and, sure enough, relaying was denied!

Which brings me back to the original complaint:

What has changed in sendmail or saslauth2 to make this extra redundant
line necessary?

Why weren't we told, and left to discover it the hard way?

Can't anyone else duplicate this problem?


One further explanation about my DNS records being not correct.
They are "correct", but a bit unusual.

1 - I have an IP  dynamically assigned by my cable company,
morrisbroadband, which can, but rarely does, change.

2 - My domain, datix.us, is purchased from godaddy.com whose webpage
allows me to set the forward reference to match my current IP, but the
reverse lookup still refers back to the morrisbroadband IP block.

Therefore, my forward and reverse DNS lookup are inconsistent, and
there's nothing I can do about it, as far as I know.
I think there are many in this same situation, and the sendmail error
message, when relaying is denied, that the IP name is possibly forged,
is unnecessarily alarmist.

Comment 3 Jaroslav Škarvada 2010-07-30 11:03:26 UTC
OK, thanks for info. On my setup, the client was 32 bit and the server was 64 bit, I retested again with both 32 bits fresh installs of Fedoras 13 and it worked as expected.

Please note that auth data is only needed on clients. The `p' option (on server) is good if you have working TLS - it denies usage of LOGIN/PLAIN auth on unsecured links. Thus if you don't use TLS you can't use the `p'. Rather use `A' without space.

Please provide your /etc/sysconfig/saslauthd. BTW theoretically you don't need special user account on server, you can change your backend (auth mech) in /etc/sysconfig/saslauthd and use other mech than PAM (e.g. configure your mail users through LDAP or similar).

Also please try to increase sendmail loging verbosity on both server/client, add/change the LOG_LEVEL in mc files to:
 define(`confLOG_LEVEL', `14')dnl

Also please try to debug the problem, e.g. on your client:
 telnet YOURSERVER 25
 ehlo localhost
 auth login
 BASE64_USERNAME
 BASE64_PASSWORD
^^^ now it should succesfully authenticate you, if not the problem is on your server and please send me your logs, if OK, continue:
 mail from: YOURMAIL
 rcpt to: DESTMAIL
 data
 subject: SUBJECT

 MESSAGE
 .
^^^ now it should rely, you can retest without auth step and it should reject

How to obtain BASE_64*:
 echo -n USERNAME | base64
 echo -n PASSWORD | base64 

Also you can debug your sasl, please try the following on your server:
 setenforce 0
 /etc/init.d/saslauthd stop
 pkill -9 saslauthd
 saslauthd -n 1 -d -a pam

And then try to authenticate from laptop. Maybe it will reveal something useful.

Comment 4 David A. De Graaf 2010-08-01 23:52:16 UTC
I'm about ready to give up on this problem and declare victory.
Relaying works OK with the augmented Sendmail.conf file - added line of
    mech_list: LOGIN PLAIN
so that's good enough...

I did run the telnet test you suggested, both with standard Sendmail.conf
and with the augmented Sendmail.conf.  The complete text is pasted below.
However, the notable difference is the AUTH line:

with standard Sendmail.conf:
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN

with augmented Sendmail.conf:
250-AUTH LOGIN PLAIN

In both cases authentication was successful and the message was
accepted for delivery, but the first one (non-augmented) never arrived
at yahoo.com, while the second one did.  I could not find the expected
"relaying denied" in the maillog file for the first case;  that file
was ginormous due to the high debug level, and lots of other activity
during my manual typing.

The "relaying denied" is clearly present in the server log when I submit via mutt, with non-augmented Sendmail.conf.


The suggested test with  saslauthd -n 1 -d -a pam  revealed nothing
to me.

Thank you for your help, but I'm willing to declare this BZ abandoned.

Manual telnet, with std Sendmail.conf:

[dad@datasus ~]
$ telnet datix.us 25
Trying 24.246.129.141...
Connected to datix.us.
Escape character is '^]'.
220 datium.datix.lan ESMTP Sendmail 8.14.4/8.14.4; Sun, 1 Aug 2010
17:09:18 -0400
ehlo localhost
250-datium.datix.lan Hello host-24-246-129-141.morrisbb.com
[24.246.129.141] (may be forged), pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-DELIVERBY
250 HELP
auth login
334 VXNlcm5hbWU6
ZGFk
334 UGFzc3dvcmQ6
cmhvZGVzMTk=
235 2.0.0 OK Authenticated
mail from: dad@datix.us
250 2.1.0 dad@datix.us... Sender ok
rcpt to: degraaf_da@yahoo.com
250 2.1.5 degraaf_da@yahoo.com... Recipient ok
data
354 Enter mail, end with "." on a line by itself
Subject: test 5
This is test 5.  with std Sendmail.conf
l
.
250 2.0.0 o71L9IaI008606 Message accepted for delivery
^]
telnet> quit
Connection closed.
[dad@datasus ~]
$




Again, with Sendmail.conf containing added line

[dad@datasus ~]
$ telnet datix.us 25
Trying 24.246.129.141...
Connected to datix.us.
Escape character is '^]'.
220 datium.datix.lan ESMTP Sendmail 8.14.4/8.14.4; Sun, 1 Aug 2010
17:15:53 -0400
ehlo localhost
250-datium.datix.lan Hello host-24-246-129-141.morrisbb.com
[24.246.129.141] (may be forged), pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-DELIVERBY
250 HELP
auth login
334 VXNlcm5hbWU6
ZGFk
334 UGFzc3dvcmQ6
cmhvZGVzMTk=
235 2.0.0 OK Authenticated
mail from: dad@datix.us
250 2.1.0 dad@datix.us... Sender ok
rcpt to: degraaf_da@yahoo.com
250 2.1.5 degraaf_da@yahoo.com... Recipient ok
data
354 Enter mail, end with "." on a line by itself
Subject: Test 6
Another manually entered message,
with augmented Sendmail.conf
.
250 2.0.0 o71LFr61008955 Message accepted for delivery
^]
telnet> quit
Connection closed.

Comment 5 Jaroslav Škarvada 2010-08-02 08:16:08 UTC
Hmm, that's really interesting. Apparently the SASL auth is working for you, but I cannot understand why it is failing to deliver if you are sucessfully authenticated. Maybe some SASL mechs in your installation interfere? Probably it would require more debugging to find out the step when it fails. I will need server logs to investigate it further. In my lab setup everything is working OK, I also tested with several mail clients. Please try to verify your installation:

 rpm -Va "sendmail*" "cyrus-sasl*"

Also please try to remove all auths from your sendmail.mc you don't have installed/configured/supported, e.g. leave in your sendmail.mc only "LOGIN PLAIN", because the client can take and use any mech from AUTH line. Some clients are smart to try more mechs if the first taken fails (at least the CRAM-MD5 should not work if the password stored on your server is not decryptable/plaintext - and by default it isn't), some clients only fails. This should have the same effect as forcing LOGIN/PLAIN through sasl config. But this doesn't explain why the delivery fails if you are successfully authenticated. 

Also if you are OK with your solution, I can close this as "works for me", because I cannot reproduce it and I have no more similar bugreports.

Comment 6 David A. De Graaf 2010-08-02 16:15:53 UTC
OK,  Jaroslav Škarvada,  since you seem willing and able to help, here's one
more cycle of info.

$ rpm -Va "sendmail*" "cyrus-sasl*"
S.5....T.  c /etc/mail/access
S.5....T.  c /etc/mail/local-host-names
S.5....T.  c /etc/mail/sendmail.cf
S.5....T.  c /etc/mail/sendmail.mc
.......T.  c /usr/lib/sasl2/Sendmail.conf

The Sendmail.conf file is back to its standard state with just one line,
although it'x been edited, so the timestamp is wrong.
The access and local-host-names have normal changes.
The sendmail.mc has been modified for local configuration including setting the
debug level to 14, and deleting all auth mechanisms except "LOGIN PLAIN".
I'll include the complete sendmail.mc below, if possible.

Now I'll send a test message from mutt on the laptop to yahoo.com, and
try to capture /var/log/maillog on the server for just that transaction.
I'll expect to see "Relaying denied", because Sendmail.conf is back to
its standard content.

Eureka.  Relaying was NOT denied; it worked!  
The message did arrive at yahoo.com.
Here's /var/log/maillog:

Aug  2 11:53:07 datium sendmail[24324]: NOQUEUE: connect from host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged)
Aug  2 11:53:07 datium sendmail[24324]: AUTH: available mech=PLAIN DIGEST-MD5 CRAM-MD5 GSSAPI LOGIN ANONYMOUS, allowed mech=LOGIN PLAIN
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: Milter (milter-greylist): init success to negotiate
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: Milter (clamav-milter): init success to negotiate
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: Milter: connect to filters
Aug  2 11:53:07 datium milter-greylist: smfi_getsymval failed for {daemon_port}, using default smtp port
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=connect, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=connect, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=helo, continue
Aug  2 11:53:07 datium sendmail[24324]: AUTH=server, relay=host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged), authid=dad, mech=LOGIN, bits=0
Aug  2 11:53:07 datium milter-greylist: User dad authenticated, bypassing greylisting
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=mail, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=mail, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=rcpt, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=rcpt, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: from=<dad@datix.us>, size=814, class=0, nrcpts=1, msgid=<20100802155306.GB18086@datasus.datix.lan>, proto=ESMTP, daemon=MTA, relay=host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged)
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=eoh, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=milter-greylist, action=body, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: Milter add: header: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (datium.datix.lan [192.168.2.2]); Mon, 02 Aug 2010 11:53:07 -0400 (EDT)
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=header, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: milter=clamav-milter, action=body, continue
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: Milter add: header: X-Virus-Scanned: clamav-milter 0.95.3 at datium.datix.lan
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: Milter add: header: X-Virus-Status: Clean
Aug  2 11:53:07 datium sendmail[24324]: o72Fr7Pp024324: Milter accept: message
Aug  2 11:53:07 datium sendmail[24330]: o72Fr7Pp024324: SMTP outgoing connect on datium.datix.lan
Aug  2 11:53:07 datium sendmail[24330]: AUTH=client, relay=mail.morrisbb.net., mech=, bits=0
Aug  2 11:53:12 datium sendmail[24330]: o72Fr7Pp024324: to=<degraaf_da@yahoo.com>, ctladdr=<dad@datix.us> (501/501), delay=00:00:05, xdelay=00:00:05, mailer=relay, pri=120814, relay=mail.morrisbb.net. [209.55.3.146], dsn=2.0.0, stat=Sent (OK id=1OfxCX-00025H-OO)
Aug  2 11:53:13 datium sendmail[24330]: o72Fr7Pp024324: done; delay=00:00:06, ntries=1



Here's the sendmail.mc in use for this experiment:

divert(-1)dnl
dnl #
dnl # This is the sendmail macro config file for m4. If you make changes to
dnl # /etc/mail/sendmail.mc, you will need to regenerate the
dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is
dnl # installed and then performing a
dnl #
dnl #     /etc/mail/make
dnl #
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for linux')dnl
OSTYPE(`linux')dnl
dnl #
dnl # Do not advertize sendmail version.
dnl #
dnl define(`confSMTP_LOGIN_MSG', `$j Sendmail; $b')dnl
dnl #
dnl # default logging level is 9, you might want to set it higher to
dnl # debug the configuration
dnl #
dnl define(`confLOG_LEVEL', `9')dnl
define(`confLOG_LEVEL', `14')dnl
dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #
define(`SMART_HOST', [mail.morrisbb.net])dnl
dnl define(`SMART_HOST', [mail.mchsi.com])dnl
dnl #
define(`confDEF_USER_ID', ``8:12'')dnl
dnl define(`confAUTO_REBUILD')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST', `True')dnl
define(`confDONT_PROBE_INTERFACES', `True')dnl
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A ')dnl
dnl #
INPUT_MAIL_FILTER(`milter-greylist', `S=local:/var/run/milter-greylist/milter-greylist.sock, T=S:4m;R:4m')dnl
INPUT_MAIL_FILTER(`clamav-milter', `S=local:/var/run/clamav-milter/clamav.sock, T=S:4m;R:4m')dnl
dnl # The following allows relaying if the user authenticates, and disallows
dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links
dnl #
dnl define(`confAUTH_OPTIONS', `A p')dnl
dnl # 
dnl # PLAIN is the preferred plaintext authentication method and used by
dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do
dnl # use LOGIN. Other mechanisms should be used if the connection is not
dnl # guaranteed secure.
dnl # Please remember that saslauthd needs to be running for AUTH. 
dnl #
dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
dnl FEATURE(`authinfo',`hash /etc/mail/auth/client-info')dnl
dnl #
dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl #     cd /etc/pki/tls/certs; make sendmail.pem
dnl # Complete usage:
dnl #     make -C /etc/pki/tls/certs usage
dnl #
dnl define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
dnl define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
dnl define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.pem')dnl
dnl define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.pem')dnl
dnl #
dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's
dnl # slapd, which requires the file to be readble by group ldap
dnl #
dnl define(`confDONT_BLAME_SENDMAIL', `groupreadablekeyfile')dnl
dnl #
dnl define(`confTO_QUEUEWARN', `4h')dnl
dnl define(`confTO_QUEUERETURN', `5d')dnl
dnl define(`confQUEUE_LA', `12')dnl
dnl define(`confREFUSE_LA', `18')dnl
define(`confTO_IDENT', `0')dnl
dnl FEATURE(delay_checks)dnl
FEATURE(`no_default_msa', `dnl')dnl
FEATURE(`smrsh', `/usr/sbin/smrsh')dnl
FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl #
dnl # The following limits the number of processes sendmail can fork to accept 
dnl # incoming messages or process its message queues to 20.) sendmail refuses 
dnl # to accept connections once it has reached its quota of child processes.
dnl #
dnl define(`confMAX_DAEMON_CHILDREN', `20')dnl
dnl #
dnl # Limits the number of new connections per second. This caps the overhead 
dnl # incurred due to forking new sendmail processes. May be useful against 
dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address 
dnl # limit would be useful but is not available as an option at this writing.)
dnl #
dnl define(`confCONNECTION_RATE_THROTTLE', `3')dnl
dnl #
dnl # The -t option will retry delivery if e.g. the user runs over his quota.
dnl #
FEATURE(local_procmail, `', `procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl #
dnl # For using Cyrus-IMAPd as POP3/IMAP server through LMTP delivery uncomment
dnl # the following 2 definitions and activate below in the MAILER section the
dnl # cyrusv2 mailer.
dnl #
dnl define(`confLOCAL_MAILER', `cyrusv2')dnl
dnl define(`CYRUSV2_MAILER_ARGS', `FILE /var/lib/imap/socket/lmtp')dnl
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 587 for
dnl # mail from MUAs that authenticate. Roaming users who can't reach their
dnl # preferred sendmail daemon due to port 25 being blocked or redirected find
dnl # this useful.
dnl #
dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl #
dnl # For this to work your OpenSSL certificates must be configured.
dnl #
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
dnl #
dnl # The following causes sendmail to additionally listen on the IPv6 loopback
dnl # device. Remove the loopback address restriction listen to the network.
dnl #
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl
dnl #
dnl # enable both ipv6 and ipv4 in sendmail:
dnl #
dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')
dnl #
dnl # We strongly recommend not accepting unresolvable domains if you want to
dnl # protect yourself from spam. However, the laptop and users on computers
dnl # that do not have 24x7 DNS do need this.
dnl #
dnl FEATURE(`accept_unresolvable_domains')dnl
dnl #
dnl FEATURE(`relay_based_on_MX')dnl
dnl # 
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl # 
LOCAL_DOMAIN(`localhost.localdomain')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
MASQUERADE_AS(`datix.us')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
FEATURE(masquerade_entire_domain)dnl
FEATURE(local_no_masquerade)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
MASQUERADE_DOMAIN(datix.lan)dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
dnl MAILER(cyrusv2)dnl



Next, I will restore the auth mechanisms, one by one, to see which one causes
breakage.  I'll report the results later.

Comment 7 David A. De Graaf 2010-08-02 17:45:01 UTC
I've restored the auth mechanisms, one by one, in

TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
                                        ^^^^^^

The culprit, the item that makes relaying fail, is the GSSAPI element
in confAUTH_MECHANISMS.

When only this is removed, relaying works.
When it is restored, relaying is denied.

I confess, none of these "auth mechanisms" make sense to me, so I simply
grope thru empirical tests.  For example, are LOGIN and PLAIN two mechanisms?
If not, why isn't it hyphenated like the rest?   LOGIN-PLAIN
Why does the default sendmail.mc list GSSAPI in confAUTH_MECHANISMS, but
not in TRUST_AUTH_MECH?

My guess, and it's only a guess, is that confAUTH_MECHANISMS lists all
potential auth mechanisms that are available, while TRUST_AUTH_MECH lists
those that can actually be trusted to do the right thing.

Where does that leave GSSAPI?  

GSSAPI is listed only once in sendmail.mc.  Nowhere is it explained what this
thing is or does.

Clearly, sendmail works better without it (for me).


I'm now using the standard Sendmail.conf, and have deleted GSSAPI from
sendmail.mc.
I'm happy, but still mystified.

Comment 8 Jaroslav Škarvada 2010-08-03 14:13:39 UTC
confAUTH_MECHANISMS defines auth mechs the client is allowed to use for auth. These mechs are advertised on AUTH line during SMTP session.

TRUST_AUTH_MECH defines mechs that are considered safe, e.g. when the client successfully authenticate by one of these mechs it is considered to be trusted and allowed to rely.

LOGIN and PLAIN are similar but not the same - the auth procedure differs. For details you can see for example: http://www.fehcom.de/qmail/smtpauth.html##FRAMEWORK

GSSAPI is standard and API for client-server authentication, AFAIK mostly the Kerberos implementation is behind - AFAIK if you don't have Kerberos server you don't need GSSAPI.

Your sendmail.mc looks good but I still cannot reproduce this. Do you use Kerberos for something? I can investigate this further but I will need the maillog when the delivery fails and also the saslauthd debug output (during the failure). Also please provide your /etc/sysconfig/saslauthd and maybe the /etc/mail/access.

Comment 9 David A. De Graaf 2010-08-03 17:20:55 UTC
I will run this experiment:
-  Edit sendmail.mc to set debug to 14;  to add GSSAPI back in to
   confAUTH_MECHANISMS, which should cause "relaying denied".
-  Run the debug sasl procedure specified in Comment 3
-  Send a message from laptop to yahoo.com to be relayed thru datix.us
-  Capture /var/log/maillog and the output of the sasl debug during this.
-  Display my /etc/sysconfig/saslauthd, which is completely standard because
   I never knew of it's existence.
-  Display /etc/mail/access.

I do not knowingly use Kerberos;  wouldn't know how to.
Nor any of the other fancy new auth mechanisms.  Good old userid and passwd
I understand since early days of UNIX.  They work fine for me.   :-)

This will generate a tsunami of data.  Ready?

***   sasl debug

[root@datium /etc/init.d]
#  setenforce 0
setenforce: SELinux is disabled
[root@datium /etc/init.d]
#  /etc/init.d/saslauthd stop
Stopping saslauthd:                                        [  OK  ]
[root@datium /etc/init.d]
#  pkill -9 saslauthd
[root@datium /etc/init.d]
#  saslauthd -n 1 -d -a pam
saslauthd[6053] :main            : num_procs  : 1
saslauthd[6053] :main            : mech_option: NULL
saslauthd[6053] :main            : run_path   : /var/run/saslauthd
saslauthd[6053] :main            : auth_mech  : pam
saslauthd[6053] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[6053] :detach_tty      : master pid is: 0
saslauthd[6053] :ipc_init        : listening on socket: /var/run/saslauthd/mux
saslauthd[6053] :main            : using process model
saslauthd[6053] :get_accept_lock : acquired accept lock

***   nothing further was emitted during email submission from mutt on laptop;
but see below for later telnet submission.


***   /var/log/maillog

Aug  3 12:08:24 datium sendmail[6183]: NOQUEUE: connect from host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged)
Aug  3 12:08:24 datium sendmail[6183]: AUTH: available mech=PLAIN DIGEST-MD5 CRAM-MD5 GSSAPI LOGIN ANONYMOUS, allowed mech=EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
Aug  3 12:08:24 datium sendmail[6183]: o73G8OKf006183: Milter (milter-greylist): init success to negotiate
Aug  3 12:08:24 datium sendmail[6183]: o73G8OKf006183: Milter (clamav-milter): init success to negotiate
Aug  3 12:08:24 datium sendmail[6183]: o73G8OKf006183: Milter: connect to filters
Aug  3 12:08:24 datium milter-greylist: smfi_getsymval failed for {daemon_port}, using default smtp port
Aug  3 12:08:24 datium sendmail[6183]: o73G8OKf006183: milter=milter-greylist, action=connect, continue
Aug  3 12:08:24 datium sendmail[6183]: o73G8OKf006183: milter=clamav-milter, action=connect, continue
Aug  3 12:08:24 datium sendmail[6183]: o73G8OKf006183: milter=milter-greylist, action=helo, continue
Aug  3 12:08:25 datium sendmail[6183]: o73G8OKf006183: host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Aug  3 12:08:25 datium sendmail[6188]: NOQUEUE: connect from host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged)
Aug  3 12:08:25 datium sendmail[6188]: AUTH: available mech=PLAIN DIGEST-MD5 CRAM-MD5 GSSAPI LOGIN ANONYMOUS, allowed mech=EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: Milter (milter-greylist): init success to negotiate
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: Milter (clamav-milter): init success to negotiate
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: Milter: connect to filters
Aug  3 12:08:25 datium milter-greylist: smfi_getsymval failed for {daemon_port}, using default smtp port
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: milter=milter-greylist, action=connect, continue
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: milter=clamav-milter, action=connect, continue
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: milter=milter-greylist, action=helo, continue
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: milter=milter-greylist, action=mail, continue
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: milter=clamav-milter, action=mail, continue
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: ruleset=check_rcpt, arg1=<degraaf_da@yahoo.com>, relay=host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged), reject=550 5.7.1 <degraaf_da@yahoo.com>... Relaying denied. IP name possibly forged [24.246.129.141]
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: Milter (milter-greylist): abort filter
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: Milter (clamav-milter): abort filter
Aug  3 12:08:25 datium sendmail[6188]: o73G8Phm006188: from=<dad@datix.us>, size=872, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged)

***   Note " Relaying denied. "


***   /etc/sysconfig/saslauthd

# Directory in which to place saslauthd's listening socket, pid file, and so
# on.  This directory must already exist.
SOCKETDIR=/var/run/saslauthd

# Mechanism to use when checking passwords.  Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.
MECH=pam

# Options sent to the saslauthd. If the MECH is other than "pam" uncomment the next line.
# DAEMONOPTS=--user saslauth

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.
FLAGS=

***   END


***   /etc/mail/access

# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file)
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
#
# If you want to use AuthInfo with "M:PLAIN LOGIN", make sure to have the 
# cyrus-sasl-plain package installed.
#
# By default we allow relaying from localhost...
Connect:localhost.localdomain           RELAY
Connect:localhost                       RELAY
Connect:127.0.0.1                       RELAY

Connect:datix.lan               RELAY
Connect:datix.us                RELAY
# From:datix.lan                  RELAY
# To:datix.lan                    RELAY
To:datix.us                OK
To:datix.lan               OK
Connect:192.168                 RELAY
Connect:dino.lan                RELAY
Connect:seby1                   RELAY
Connect:redcat.lan              RELAY
From:garfield.redcat.lan        OK

# spam@imaspammer.com           REJECT
#
# As recommended in http://fedoraproject.org/wiki/UOL
Connect:uol.com.br REJECT uol.com.br blacklisted for broken anti-spam.

Connect:72.11                   REJECT  72.11 blacklisted for spam

***   END



Since there was no action in the sasl debug window when the message was sent
by mutt from the laptop, I continued the experiment by entering a message 
manually via   telnet datix.us 25   as you described in Comment 3.
During the auth operation, the sasl debug showed these added lines:

saslauthd[6053] :rel_accept_lock : released accept lock
saslauthd[6053] :do_auth         : auth success: [user=dad] [service=smtp] [realm=] [mech=pam]
saslauthd[6053] :do_request      : response: OK
saslauthd[6053] :get_accept_lock : acquired accept lock


During that submission /var/log/maillog received these lines:


Aug  3 12:30:00 datium dovecot: imap-login: Login: user=<dad>, method=PLAIN, rip=192.168.2.119, lip=192.168.2.2

Aug  3 12:30:00 datium dovecot: IMAP(dad): Disconnected: Logged out bytes=50/403
Aug  3 12:30:08 datium sendmail[7179]: NOQUEUE: connect from host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged)
Aug  3 12:30:08 datium sendmail[7179]: AUTH: available mech=PLAIN DIGEST-MD5 CRAM-MD5 GSSAPI LOGIN ANONYMOUS, allowed mech=EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
Aug  3 12:30:08 datium sendmail[7179]: o73GU8PI007179: Milter (milter-greylist): init success to negotiate
Aug  3 12:30:08 datium sendmail[7179]: o73GU8PI007179: Milter (clamav-milter): init success to negotiate
Aug  3 12:30:08 datium sendmail[7179]: o73GU8PI007179: Milter: connect to filters
Aug  3 12:30:08 datium milter-greylist: smfi_getsymval failed for {daemon_port}, using default smtp port
Aug  3 12:30:08 datium sendmail[7179]: o73GU8PI007179: milter=milter-greylist, action=connect, continue
Aug  3 12:30:08 datium sendmail[7179]: o73GU8PI007179: milter=clamav-milter, action=connect, continue
Aug  3 12:30:14 datium sendmail[7179]: o73GU8PI007179: milter=milter-greylist, action=helo, continue
Aug  3 12:30:32 datium sendmail[7179]: AUTH=server, relay=host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged), authid=dad, mech=login, bits=0
Aug  3 12:30:59 datium milter-greylist: User dad authenticated, bypassing greylisting
Aug  3 12:30:59 datium sendmail[7179]: o73GU8PI007179: milter=milter-greylist, action=mail, continue
Aug  3 12:30:59 datium sendmail[7179]: o73GU8PI007179: milter=clamav-milter, action=mail, continue
Aug  3 12:31:00 datium dovecot: imap-login: Login: user=<dad>, method=PLAIN, rip=24.246.129.141, lip=192.168.2.2
Aug  3 12:31:00 datium dovecot: IMAP(dad): Disconnected: Logged out bytes=50/403
Aug  3 12:31:20 datium sendmail[7179]: o73GU8PI007179: milter=milter-greylist, action=rcpt, continue
Aug  3 12:31:20 datium sendmail[7179]: o73GU8PI007179: milter=clamav-milter, action=rcpt, continue
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: from=dad@datix.us, size=31, class=0, nrcpts=1, msgid=<201008031631.o73GU8PI007179@datium.datix.lan>, proto=ESMTP, daemon=MTA, relay=host-24-246-129-141.morrisbb.com [24.246.129.141] (may be forged)
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: milter=milter-greylist, action=eoh, continue
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: milter=milter-greylist, action=body, continue
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: Milter add: header: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (datium.datix.lan [192.168.2.2]); Tue, 03 Aug 2010 12:31:40 -0400 (EDT)
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: milter=clamav-milter, action=header, continue
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: milter=clamav-milter, action=body, continue
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: Milter add: header: X-Virus-Scanned: clamav-milter 0.95.3 at datium.datix.lan
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: Milter add: header: X-Virus-Status: Clean
Aug  3 12:31:40 datium sendmail[7179]: o73GU8PI007179: Milter accept: message
Aug  3 12:31:40 datium sendmail[7244]: o73GU8PI007179: SMTP outgoing connect on datium.datix.lan
Aug  3 12:31:45 datium sendmail[7244]: AUTH=client, relay=mail.morrisbb.net., mech=, bits=0


Aug  3 12:32:28 datium sendmail[7244]: o73GU8PI007179: to=degraaf_da@yahoo.com, ctladdr=dad@datix.us (501/501), delay=00:01:08, xdelay=00:00:48, mailer=relay, pri=120031, relay=mail.morrisbb.net. [209.55.3.146], dsn=2.0.0, stat=Sent (OK id=1OgKPf-0004cA-UC)
Aug  3 12:32:28 datium sendmail[7244]: o73GU8PI007179: done; delay=00:01:08, ntries=1


I did this twice, failing to capture the complete  maillog  on the first try.
Both manually entered messages were relayed, and received at yahoo.com.

It is apparent that relaying is denied when mutt submits a message,
which produces no evidence of  sasl  action,
but succeeds when the message is entered via telnet.
Therefore the failure to relay must be in some way due to a peculiarity of
mutt's sending method.

I can't tell if the silence in the sasl debug during mutt's submission is
because sasl is silent when auth fails, or because mutt simply bypasses sasl.


I can test that.  I'll delete GSSAPI again from sendmail.mc so that relaying
succeeds, and send another message from mutt on the laptop.  Here goes.

Result:  There was auth activity in the sasl debug window identical to that
previously seen when telnet submitted the message:

saslauthd[6053] :rel_accept_lock : released accept lock
saslauthd[6053] :do_auth         : auth success: [user=dad] [service=smtp] [realm=] [mech=pam]
saslauthd[6053] :do_request      : response: OK
saslauthd[6053] :get_accept_lock : acquired accept lock


The relaying succeeded.  I won't regurgitate the maillog.  It showed success.
and the message did arrive at yahoo.com.

So, when GSSAPI is present, sasl debug shows no activity when mutt submits,
but does show auth activity when telnet submits.
When GSSAPI is absent, mutt does trigger sasl  auth activity.

Comment 10 Jaroslav Škarvada 2010-08-04 07:35:18 UTC
Thanks for data, now it is clear.

You don't use Kerberos, thus the GSSAPI auth fails. Your mail client (mutt) reads advertised AUTH mechs, sees GSSAPI and prefers it over other auth mechs (as it is more safe than LOGIN/PLAIN). Please note that the mail client can choose *ANY* of the advertised auth mechs. Some clients tries more auth mechs in sequence if the first selected fails, some not. Probably that's your case - the mutt tries the most preferred available auth mech (GSSAPI). The auth fails because the backend on your server is not configured and that's why the mutt continues without auth resulting in relaying denied. The sequence of auth mechs is probably hardcoded to mutt or is user configurable, I do not have the mutt source code here to check.

Also please note that you can instruct the sendmail client to use only the subset of auth mechs available on the server you are connecting to, e.g. something similar to the following authlist that forces the sendmail client to use only the LOGIN/PLAIN:

AuthInfo:your.mailserver.com "U:root" "I:username@your.mailserver.com" "P:password" "M:LOGIN PLAIN"

But that's not clear solution. Please note that all auth mechs your server advertises should be correctly configured and working. You shouldn't advertise auth mechs that are not correctly configured and thus unusable for authentication.

Thus I do not recognize this as a bug and I am closing it. If you are not happy with this conclusion, feel free to reopen.

Comment 11 David A. De Graaf 2010-08-05 17:11:38 UTC
OK,  Jaroslav Škarvada.  Your explanation makes perfect sense,
and I will delete all but `LOGIN PLAIN' from my server.

You are correct in closing this BZ.

However, there remains a philosophical discussion, which if pursued 
might even improve future releases.

-  Something must have changed.  Fedora 12 worked perfectly for me
with my original configuration, but Fedora 13 suddenly has different
behaviour.  It has become less tolerant.  That is NOT a Good Thing.

Perhaps that's just the price to pay for all the other good stuff.

However, it is incorrect to ascribe this behaviour to mutt, since mutt
possesses no SMTP capability; it merely passes outgoing mail to sendmail
at localhost.  Whatever transmission occurs is between sendmail and
sendmail.

-  Since sendmail/saslauthd have become unable to negotiate properly
in the face of non-working but advertised capabilities,
would it be possible/desirable to add a simple comment line to
sendmail.mc warning of this,  say,
   dnl # Do not include in TRUST_AUTH_MECH or confAUTH_MECHANISMS items
   dnl # that are not configured for use, else connections may fail.
   
Thank you for all your help.


Note You need to log in before you can comment on or make changes to this bug.