headers
Leonhard Knauff | 1 Apr 2011 07:46
Picon
Favicon

logging "badlogin imap" via ME/UWC ?

Hallo together,

Sun Java(tm) System Messaging Server 6.3-11.01 (built Feb 12 2010; 32bit)
libimta.so 6.3-11.01 (built 11:46:00, Feb 12 2010; 32bit)
SunOS mserv3 5.10 Generic_127111-02 sun4v sparc SUNW,SPARC-Enterprise-T2000
(Patch 120228-40, 120228-42 do the same)

logfile.imap.loglevel = Information

We use:
     POP native  (Thunderbird & Co.)
     IMAP native (Thunderbird & Co.)
     Messenger Express ME via IMAP
     Communication Express UWC via IMAP

Problem with "bad login" logging IMAP:
   if "Wrong password used" ...

  1. With IMAP native (Thunderbird & Co.):
      For a wrong password:  In the logfile "log/imap":
         imapd[2791]: Account Notice: badlogin: [99.99.99.99:50958] 
                       plaintext XXXXX authentication failure
      That is OK and fine.

  2. With IMAP via ME or UWC:
      For a wrong password:  In the logfile "log/imap":
         ---------->   No entry   :-(((((((

  3. Only in the "log/http" of ME I found 
         httpd[2800]: Account Notice: badlogin: [192.168.1.1:51436]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marko Jauhiainen | 4 Apr 2011 11:11
Picon
Picon

Logging Message-Id with LMTP

Hi,

[Running Oracle Communications Messaging Exchange Server 7u4-19.01 64bit 
(built Sep  7 2010)
libimta.so 7u4-19.01 64bit (built 13:35:06, Sep  7 2010)]

Is there a way to log Message-Id in the back-end store that uses (only) 
LMTP to receive messages from the MTA? Currently a typical line in the 
log file (mail.log[_current]) looks like this:

04-Apr-2011 00:30:26.67 4da2.163c.17505 tcp_lmtpss                S 0 
firstname.lastname@... rfc822; username <at> lmtpcs-daemon 
mtahost.ourdomain.fi (mtahost.ourdomain.fi [123.167.88.45])    250 2.5.0 
Delivery to user OK   0

Judging by the documentation I've seen so far, I'd be inclined to say, 
'no'. But I frequently find that not all the relevant documentation is 
where one would think it is, nor is it always correct (not to mention 
the possibility of misunderstanding it :).

Marko
Permalink | Reply | 6 comments |
headers
Dan Newman | 4 Apr 2011 16:26
Picon
Favicon

Re: Logging Message-Id with LMTP

Have you set LOG_MESSAGE_ID=1 in the option.dat file?  See, e.g.,

http://wikis.sun.com/display/CommSuite/Managing+Logging

You will then need to recompile the configuration if using a compiled
configuration.  Then restart the Dispatcher so as to start new
LMTP processes.  (Note that currently busy LMTP server processes will
not exit until all their active, inbound sessions have finished.)

Dan

On 4 Apr 2011 , at 2:11 AM, Marko Jauhiainen wrote:

> Hi,
> 
> [Running Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep  7 2010)
> libimta.so 7u4-19.01 64bit (built 13:35:06, Sep  7 2010)]
> 
> Is there a way to log Message-Id in the back-end store that uses (only) LMTP to receive messages from the
MTA? Currently a typical line in the log file (mail.log[_current]) looks like this:
> 
> 04-Apr-2011 00:30:26.67 4da2.163c.17505 tcp_lmtpss                S 0
firstname.lastname@... rfc822; username <at> lmtpcs-daemon
mtahost.ourdomain.fi (mtahost.ourdomain.fi [123.167.88.45])    250 2.5.0 Delivery to user OK   0
> 
> Judging by the documentation I've seen so far, I'd be inclined to say, 'no'. But I frequently find that not
all the relevant documentation is where one would think it is, nor is it always correct (not to mention the
possibility of misunderstanding it :).
> 
> Marko
(Continue reading)

Permalink | Reply | 4 comments |
headers
Marko Jauhiainen | 4 Apr 2011 16:34
Picon
Picon

Re: Logging Message-Id with LMTP


On 4.4.2011 17:26, Dan Newman wrote:
> Have you set LOG_MESSAGE_ID=1 in the option.dat file?  See, e.g.,
>
> http://wikis.sun.com/display/CommSuite/Managing+Logging
>
> You will then need to recompile the configuration if using a compiled
> configuration.  Then restart the Dispatcher so as to start new
> LMTP processes.  (Note that currently busy LMTP server processes will
> not exit until all their active, inbound sessions have finished.)

I have had that option set since last spring. But when we switched from 
SMTP to LMTP delivery during the summer, Message-id was no longer logged 
in mail.log. The store host has been restarted n+1 times since the change.

I must be missing something obvious here...?

Marko

>
> Dan
>
>
> On 4 Apr 2011 , at 2:11 AM, Marko Jauhiainen wrote:
>
>> Hi,
>>
>> [Running Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep  7 2010)
>> libimta.so 7u4-19.01 64bit (built 13:35:06, Sep  7 2010)]
>>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kelly Caudill | 4 Apr 2011 16:44
Picon
Favicon

Re: Logging Message-Id with LMTP

RFE 6258366: have the lmtp server log message ID in the mail.log.
closed as "not a defect".

Evaluation: The omission of the message id from the LMTP server log is expected 
behavior.  Moreover, it is important that it not be changed. The entire idea 
behind LMTP is to minimize the amount of work done on the backend store while 
delivering mail.  To this end, the LMTP server doesn't scan the content of the 
message for any purpose, which would be necessary to extract information like 
the message id.

Why do you want this information?  Why is it not sufficient to get it from a 
front-end MTA?

Kelly

On 4/4/2011 10:34 AM, Marko Jauhiainen wrote:
>
>
> On 4.4.2011 17:26, Dan Newman wrote:
>> Have you set LOG_MESSAGE_ID=1 in the option.dat file? See, e.g.,
>>
>> http://wikis.sun.com/display/CommSuite/Managing+Logging
>>
>> You will then need to recompile the configuration if using a compiled
>> configuration. Then restart the Dispatcher so as to start new
>> LMTP processes. (Note that currently busy LMTP server processes will
>> not exit until all their active, inbound sessions have finished.)
>
> I have had that option set since last spring. But when we switched from SMTP to
> LMTP delivery during the summer, Message-id was no longer logged in mail.log.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Newman | 4 Apr 2011 17:39
Picon
Favicon

Re: Logging Message-Id with LMTP


On 4 Apr 2011 , at 7:34 AM, Marko Jauhiainen wrote:

> 
> 
> On 4.4.2011 17:26, Dan Newman wrote:
>> Have you set LOG_MESSAGE_ID=1 in the option.dat file?  See, e.g.,
>> 
>> http://wikis.sun.com/display/CommSuite/Managing+Logging
>> 
>> You will then need to recompile the configuration if using a compiled
>> configuration.  Then restart the Dispatcher so as to start new
>> LMTP processes.  (Note that currently busy LMTP server processes will
>> not exit until all their active, inbound sessions have finished.)
> 
> I have had that option set since last spring. But when we switched from SMTP to LMTP delivery during the
summer, Message-id was no longer logged in mail.log. The store host has been restarted n+1 times since the change.
> 
> I must be missing something obvious here...?

Not necessarily.  To log the message id, it is necessary to parse the message's
header.  The point behind LMTP is to do all the message processing at the front
end MTAs and to then do minimal message processing on the backend stores (including,
most importantly, no store-and-forward queues on the backend stores).

As such, I'm not surprised that any logging which would require message
parsing is not occurring with LMTP delivery.  However, I figured that you
might give it a try if you hadn't already.

Dan
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ned Freed | 4 Apr 2011 17:57

Re: Logging Message-Id with LMTP

> Hi,

> [Running Oracle Communications Messaging Exchange Server 7u4-19.01 64bit
> (built Sep  7 2010)
> libimta.so 7u4-19.01 64bit (built 13:35:06, Sep  7 2010)]

> Is there a way to log Message-Id in the back-end store that uses (only)
> LMTP to receive messages from the MTA?

No. Messages are fed directly into the store; no parsing is done by the LMTP
server. So there's no easy means of extracting the message-id for logging
purposes.

> Currently a typical line in the
> log file (mail.log[_current]) looks like this:

> 04-Apr-2011 00:30:26.67 4da2.163c.17505 tcp_lmtpss                S 0
> firstname.lastname@... rfc822; username <at> lmtpcs-daemon
> mtahost.ourdomain.fi (mtahost.ourdomain.fi [123.167.88.45])    250 2.5.0
> Delivery to user OK   0

> Judging by the documentation I've seen so far, I'd be inclined to say,
> 'no'. But I frequently find that not all the relevant documentation is
> where one would think it is, nor is it always correct (not to mention
> the possibility of misunderstanding it :).

In this case the documentation is correct.

				Ned
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Newman | 5 Apr 2011 00:08
Picon
Favicon

Re: logging "badlogin imap" via ME/UWC ?

--On April 1, 2011 7:46:37 +0200 Leonhard Knauff 
<leonhard.knauff@...> wrote:
> Sun Java(tm) System Messaging Server 6.3-11.01 (built Feb 12 2010; 32bit)
> libimta.so 6.3-11.01 (built 11:46:00, Feb 12 2010; 32bit)
> SunOS mserv3 5.10 Generic_127111-02 sun4v sparc
> SUNW,SPARC-Enterprise-T2000 (Patch 120228-40, 120228-42 do the same)
>
> logfile.imap.loglevel = Information
>
>
> We use:
>      POP native  (Thunderbird & Co.)
>      IMAP native (Thunderbird & Co.)
>      Messenger Express ME via IMAP
>      Communication Express UWC via IMAP
>
> Problem with "bad login" logging IMAP:
>    if "Wrong password used" ...
>
>   1. With IMAP native (Thunderbird & Co.):
>       For a wrong password:  In the logfile "log/imap":
>          imapd[2791]: Account Notice: badlogin: [99.99.99.99:50958]
>                        plaintext XXXXX authentication failure
>       That is OK and fine.
>
>   2. With IMAP via ME or UWC:
>       For a wrong password:  In the logfile "log/imap":
>          ---------->   No entry   :-(((((((
>
>   3. Only in the "log/http" of ME I found
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marko Jauhiainen | 5 Apr 2011 12:18
Picon
Picon

Re: Logging Message-Id with LMTP


On 4.4.2011 17:44, Kelly Caudill wrote:
> RFE 6258366: have the lmtp server log message ID in the mail.log.
> closed as "not a defect".
>
> Evaluation: The omission of the message id from the LMTP server log is
> expected behavior. Moreover, it is important that it not be changed. The
> entire idea behind LMTP is to minimize the amount of work done on the
> backend store while delivering mail. To this end, the LMTP server
> doesn't scan the content of the message for any purpose, which would be
> necessary to extract information like the message id.

This is precisely how I interpreted the documentation (thanks to Dan and 
Ned for their comments, too), so I'm relieved to hear this :)

> Why do you want this information? Why is it not sufficient to get it
> from a front-end MTA?

I guess it would only be relevant in quickly (e.g., "grep <message-id> 
mail.log") making sure that the message passed on by the MTA was indeed 
delivered safely to the user's mailbox in the store host. The emphasis 
is here on the word "quickly"; I also agree that it is sufficient to get 
it from a front-end MTA.

Thanks,
Marko

>
>
> On 4/4/2011 10:34 AM, Marko Jauhiainen wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leonhard Knauff | 5 Apr 2011 12:53
Picon
Favicon

RE: logging "badlogin imap" via ME/UWC ?


Many thanks for the answer.

[.....]

> > Questions:
> >   - Does ME resp. UWC make a "preauthentication", and only if this is OK
> >     then IMAP is called?
>
> The mshttpd process lookups up the user to determine which imap mailstore
> to talk to for that user's mail. If the user is invalid, it doesn't talk to
> any imap mailstore.

OK, I forgot that there can be more as one mailstore and so the mshttpd
must read the LDAP entry.

> >   - Can be configured that also imapd logged the bad login if called
> >     via ME resp. UWC?
> >     (The good logins are logged in the imapd log file.)
>
> No. We don't want the access layer (mshttpd) to pass known-invalid
> operations to the back-end mailstore in a way that will create additional
> load on that server.

Correct.

> So even if you requested that as an RFE it would be
> rejected. However, an RFE to collect all authentication operation logs
> centrally in one place would be a valid feature request, although I can't
> predict whether or not it would have a high enough priority to get
(Continue reading)

Permalink | Reply | 0 comments |

Gmane