Ned Freed | 12 Jul 2010 23:19

Re: MSA not requiring SMTP AUTH on SMTP (HELO)


> I was doing some log parsing and noticed something odd.  On our MSA
> service, we want to require SMTP AUTH over an encrypted channel for any
> and all connections.  All seemed to be working well, until I saw the
> following log entry:

> 12-Jul-2010 08:23:32.82 4753.0dd1.8106 tcp_submit   tcp_meritmail EES 5
local.user1@...
rfc822;local.user2@...
user2@... 20
/opt/sun/comms/messaging64/data/queue/tcp_meritmail/012/ZZh034G29rfhp.00
0L5G00ETQ2F73750@...
<1B748474396348DE959D15DE907ABDCB <at> Staff001> sunmsg Staff001 (ceas145-NNN.ceas.wmich.edu
[141.218.145.NNN]) -1 3 'spamfilter1:YiLYDO1a17P5DQUg2DzbXw==, addheader, keep'   0

> Where is the A modifier code?

There isn't one because authorization wasn't used. According to the
configuration material you provided, you don't require authentication on
tcp_sibmit, so...

> Here is the slave log entry....

> 08:23:31.93: Sending    : "220 smtp.wmich.edu -- Server ESMTP (Sun Java(tm) System Messaging Server
6.3-8.01 (built Dec 16 2008; 64bit))"
> 08:23:31.93: Received   : "EHLO Staff001"

Note the use of EHLO here. The fact this command was given and accepted makes
this an ESMTP connection.

(Continue reading)

Derek Diget | 13 Jul 2010 00:31
Favicon

Re: MSA not requiring SMTP AUTH on SMTP (HELO)


On Jul 12, 2010 at 14:19 -0700, Ned Freed wrote:
=>
=>> I was doing some log parsing and noticed something odd.  On our MSA
=>> service, we want to require SMTP AUTH over an encrypted channel for any
=>> and all connections.  All seemed to be working well, until I saw the
=>> following log entry:
=>
=>> 12-Jul-2010 08:23:32.82 4753.0dd1.8106 tcp_submit   tcp_meritmail EES 5
=>> local.user1@...
rfc822;local.user2@...
user2@... 20
=>> /opt/sun/comms/messaging64/data/queue/tcp_meritmail/012/ZZh034G29rfhp.00
=>> 0L5G00ETQ2F73750@...
=>> <1B748474396348DE959D15DE907ABDCB <at> Staff001> sunmsg Staff001
=>> (ceas145-NNN.ceas.wmich.edu [141.218.145.NNN]) -1 3
=>> 'spamfilter1:YiLYDO1a17P5DQUg2DzbXw==, addheader, keep'   0
=>
=>> Where is the A modifier code?
=>
=>There isn't one because authorization wasn't used. According to the
=>configuration material you provided, you don't require authentication on
=>tcp_sibmit, so...

Sorry it was not clear, but my question was rhetorical. :)

=>> Here is the slave log entry....
=>
=>> 08:23:31.93: Sending    : "220 smtp.wmich.edu -- Server ESMTP (Sun Java(tm)
=>> System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit))"
(Continue reading)

Kristin Hubner | 13 Jul 2010 00:48
Picon

Re: MSA not requiring SMTP AUTH on SMTP (HELO)

We want to see a full log file (with the additional MM_DEBUG debugging
Ned mentioned) showing the whole session -- we want to see what occurred
before and after the snippet you showed.

Note that it quite likely makes sense to set "noswitchchannel" on your
tcp_submit channel -- that is, I doubt you have any cases where you
_want_ to switch to tcp_submit?  But whether that will help your case of
the moment depends on why the switch back to tcl_submit occurred.

Note that it is possible to use FROM_ACCESS to restrict submissions on
some channel to require both AUTH and TLS use (allow with $:T$:A; reject 
otherwise).  But I don't think you should have to bother doing such a check 
if your channel use is all set up properly -- but let's see the debug log 
file.

Regards,

Kristin

On Jul 12, 2010, at 3:31 PM, Derek Diget wrote:

> 
> On Jul 12, 2010 at 14:19 -0700, Ned Freed wrote:
> =>
> =>> I was doing some log parsing and noticed something odd.  On our MSA
> =>> service, we want to require SMTP AUTH over an encrypted channel for any
> =>> and all connections.  All seemed to be working well, until I saw the
> =>> following log entry:
> =>
> =>> 12-Jul-2010 08:23:32.82 4753.0dd1.8106 tcp_submit   tcp_meritmail EES 5
(Continue reading)

Derek Diget | 13 Jul 2010 03:36
Favicon

Re: MSA not requiring SMTP AUTH on SMTP (HELO)


On Jul 12, 2010 at 15:48 -0700, Kristin Hubner wrote:
=>We want to see a full log file (with the additional MM_DEBUG debugging
=>Ned mentioned) showing the whole session -- we want to see what occurred
=>before and after the snippet you showed.

I have enabled MM_DEBUG=3.  Hopefully the user will send something in 
the near future.

--

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

Derek Diget | 14 Jul 2010 00:09
Favicon

Re: MSA not requiring SMTP AUTH on SMTP (HELO)


On Jul 12, 2010 at 21:36 -0400, Derek Diget wrote:
=>On Jul 12, 2010 at 15:48 -0700, Kristin Hubner wrote:
=>=>We want to see a full log file (with the additional MM_DEBUG debugging
=>=>Ned mentioned) showing the whole session -- we want to see what occurred
=>=>before and after the snippet you showed.
=>
=>I have enabled MM_DEBUG=3.  Hopefully the user will send something in 
=>the near future.

User sent a message today. :)  I sent the log file directly to Ned and 
Kristin because of the size of the file.  If you are interested, let me 
know and I can send it your way, too.

Here is the mail.log_current entry for the submission

13-Jul-2010 16:58:19.64 380d.1762.14693 tcp_submit   tcp_untd     EES 7
local.user1@...
rfc822;remote.user1@...
remote.user1@... 20
/opt/sun/comms/messaging64/data/queue/tcp_untd/007/ZZh033Nihuobm.00
0L5I00B0TKX62LA0@...
<3E7BA11C345640B6902F8EC18FB3F17C <at> Staff001> sunmsg Staff001 (ceas145-NNN.ceas.wmich.edu
[141.218.145.NNN]) -1 3 'spamfilter1:WYd59ljNBKF/02nEwblfww==, addheader, keep'   0
13-Jul-2010 16:58:19.65 380d.1762.14694 tcp_submit   tcp_groupwise EES 7
local.user1@...
rfc822;local.user2@...
user2@... 20
/opt/sun/comms/messaging64/data/queue/tcp_groupwise/003/ZZh033Nihuobn.00
0L5I00B0TKX62LA0@...
(Continue reading)

Kristin Hubner | 16 Jul 2010 19:29
Picon
Favicon

Re: MSA not requiring SMTP AUTH on SMTP (HELO)

Thanks for reporting this and sending the log so we could track it down!

It's a bug.  It occurs if the client (incorrectly) sends HELO after doing 
other stuff where an EHLO was needed (such as STARTTLS) -- but in such 
cases the "switchchannel" type effects (such as tlsswitchchannel) won't take 
place properly.  Some rationalization-and-consolidation of all the "switchchannel" 
type code in MS 7.0u2 means it should be fixed for MS 7.0u2.

If you can't upgrade right away, Ned is going to make a CR # for this bug
-- there should be a simpler fix for just this problem (without
having to do the whole code-rationalization-and-consolidation that was
done for MS 7.0u2) -- so check through your support channel if you'll be
wanting a patch.

Meantime, you could use a FROM_ACCESS mapping to check for the problem
case of message submissions staying on tcp_submit (not getting switched
as "musttlsserver tlsswitchchannel tcp_submit_auth" ought to have ensured
if it weren't for the bug) and then not authenticating.  Perhaps something
like:

FROM_ACCESS

  TCP|*|SMTP*|MAIL|tcp_submit|*|*    $C$;A$NMust$ authenticate$E 

This should catch the case of submissions where even though tcp_submit
required STARTTLS and then should have switched, the switch didn't occur,
and the SMTP AUTH didn't occur.  (Actually, if you're always switching
away from tcp_submit -- you don't have any users with mailSMTPSubmitChannel
set to tcp_submit so getting an effect of switching back to tcp_submit after
authenticating -- so that tcp_submit is never supposed to show up as an
(Continue reading)


Gmane