The logging on lmtp and lmtp proxy is pretty limited from what I can see. It seems to handle errors, Connect, Disconnect, and in the case of lmtp delivery, it logs where an email is saved to. The lmtp may be enough, "connect, saved user, saved user..., disconnect", but I was curious if it is worth while to add more info logging for the proxy, primarily which recipients are sent to which proxy. I was thinking of local patching it, but I'll generate up something more inline with official code if it is desired.
My thought is to show 1 entry for each recipient, and the destination server chosen. If I recall correctly, the proxy code doesn't actually listen in on the conversation, so logging results would probably complicate the code.
Jack
On 10.10.2012, at 17.37, Jack Bates wrote:
The logging on lmtp and lmtp proxy is pretty limited from what I can see. It seems to handle errors, Connect, Disconnect, and in the case of lmtp delivery, it logs where an email is saved to. The lmtp may be enough, "connect, saved user, saved user..., disconnect", but I was curious if it is worth while to add more info logging for the proxy, primarily which recipients are sent to which proxy. I was thinking of local patching it, but I'll generate up something more inline with official code if it is desired.
My thought is to show 1 entry for each recipient, and the destination server chosen. If I recall correctly, the proxy code doesn't actually listen in on the conversation, so logging results would probably complicate the code.
I don't think this would be difficult to implement. Probably just a few lines of code. Yeah, could be useful.
On 10/12/12 2:40 AM, Timo Sirainen wrote:
On 10.10.2012, at 17.37, Jack Bates wrote:
The logging on lmtp and lmtp proxy is pretty limited from what I can see. It seems to handle errors, Connect, Disconnect, and in the case of lmtp delivery, it logs where an email is saved to. The lmtp may be enough, "connect, saved user, saved user..., disconnect", but I was curious if it is worth while to add more info logging for the proxy, primarily which recipients are sent to which proxy. I was thinking of local patching it, but I'll generate up something more inline with official code if it is desired.
My thought is to show 1 entry for each recipient, and the destination server chosen. If I recall correctly, the proxy code doesn't actually listen in on the conversation, so logging results would probably complicate the code. I don't think this would be difficult to implement. Probably just a few lines of code. Yeah, could be useful.
+1 for adding this detail to logging for LMTP.
On 10/12/2012 2:40 AM, Timo Sirainen wrote:
would probably complicate the code. I don't think this would be difficult to implement. Probably just a few lines of code. Yeah, could be useful.
Commented logs below. I did 3 different types of connections. Let me know what you think. Because I'm logging the proxy host itself, it can be IP or name depending on the configuration. If you like it, want minor changes, additional logging, let me know and I'll adjust the code. As is, this is a one liner.
Jack
Oct 12 19:03:45 compiler dovecot: lmtp(18568): Connect from ::1
Connection succeeds using static proxy to lmtp.example.com (default in this config). Oct 12 19:04:14 compiler dovecot: lmtp(18568): Reply from lmtp.example.com(test): 250 2.5.0 command succeeded
Connection succeeds but user invalid using director mapping Oct 12 19:04:14 compiler dovecot: lmtp(18568): Reply from 192.168.1.3(test2): 550 5.1.1 <test2> User doesn't exist: test2
Current error reporting Oct 12 19:04:14 compiler dovecot: lmtp(18568): Error: lmtp client: connect(192.168.1.4, 7025) failed: No route to host
Connection failed and what we returned to client Oct 12 19:04:14 compiler dovecot: lmtp(18568): Reply from 192.168.1.4(test42): 451 4.4.0 Remote server not answering (connect)
Oct 12 19:04:16 compiler dovecot: lmtp(18568): Disconnect from ::1: Client quit (in reset)
On 10/15/2012 2:07 PM, Jack Bates wrote:
On 10/12/2012 2:40 AM, Timo Sirainen wrote:
would probably complicate the code. I don't think this would be difficult to implement. Probably just a few lines of code. Yeah, could be useful.
If there's no argument over the last email, confirm and check this patch. It's not the overall logging I would like, but the lmtp code isn't as mature as pop3/imap and the proxy is a quick and dirty on the lmtp code. Both need a good revamp, preferably with x-session support and perhaps logging rip/lip similar to how we do pop3/imap logins. I think we should also work on adjusting all logging for services using x-session to also log the proxy ip. rip,lip,pip. As I get time I'll look at it. This patch is just to keep us from having no useful logging in lmtp proxy. Based on lmtp pid, one can at least follow the connect, the proxy replies, and the disconnect of a session. --- dovecot-2.1.10/src/lmtp/lmtp-proxy.c 2012-10-12 19:46:49.688952484 +0000 +++ dovecot-2.1.10/src/lmtp/lmtp-proxy.c-new 2012-10-12 19:48:51.751932325 +0000 @@ -160,6 +160,8 @@ static bool lmtp_proxy_send_data_replies break; o_stream_send_str(proxy->client_output, t_strconcat(rcpt[i]->reply, "\r\n", NULL)); + i_info("proxy(%s): proxy host=%s: status=%s",rcpt[i]->address, + rcpt[i]->conn->set.host,rcpt[i]->reply); } o_stream_uncork(proxy->client_output); proxy->next_data_reply_idx = i;
Timo, How do you feel about parent pointers in child structures? I'm curious as the proxy structure is passed the input channel, but it doesn't know much else about the input client. Rather than pass additional information in the structure, I think it'd be better to just place a pointer back to the input client so we can access all it's details. I ask, as that might solve the problem of lack of information in logging from some of the various functions in the proxy code. I know I was limited in the quick patch I did below for my own use. I'm afraid to change it too much. You have already started xclient work in v2.2 which would necessitate a lot of changes to the lmtp/proxy code. I've actually debated backporting it to 2.1 for my own use. :) Jack On 10/15/2012 3:10 PM, Jack Bates wrote:
On 10/15/2012 2:07 PM, Jack Bates wrote:
On 10/12/2012 2:40 AM, Timo Sirainen wrote:
would probably complicate the code. I don't think this would be difficult to implement. Probably just a few lines of code. Yeah, could be useful.
If there's no argument over the last email, confirm and check this patch. It's not the overall logging I would like, but the lmtp code isn't as mature as pop3/imap and the proxy is a quick and dirty on the lmtp code. Both need a good revamp, preferably with x-session support and perhaps logging rip/lip similar to how we do pop3/imap logins.
I think we should also work on adjusting all logging for services using x-session to also log the proxy ip. rip,lip,pip. As I get time I'll look at it.
This patch is just to keep us from having no useful logging in lmtp proxy. Based on lmtp pid, one can at least follow the connect, the proxy replies, and the disconnect of a session.
--- dovecot-2.1.10/src/lmtp/lmtp-proxy.c 2012-10-12 19:46:49.688952484 +0000 +++ dovecot-2.1.10/src/lmtp/lmtp-proxy.c-new 2012-10-12 19:48:51.751932325 +0000 @@ -160,6 +160,8 @@ static bool lmtp_proxy_send_data_replies break; o_stream_send_str(proxy->client_output, t_strconcat(rcpt[i]->reply, "\r\n", NULL)); + i_info("proxy(%s): proxy host=%s: status=%s",rcpt[i]->address, + rcpt[i]->conn->set.host,rcpt[i]->reply); } o_stream_uncork(proxy->client_output); proxy->next_data_reply_idx = i;
On 18.10.2012, at 6.48, Jack Bates wrote:
How do you feel about parent pointers in child structures? I'm curious as the proxy structure is passed the input channel, but it doesn't know much else about the input client. Rather than pass additional information in the structure, I think it'd be better to just place a pointer back to the input client so we can access all it's details.
Generally speaking it's cleaner to keep things as separate as possible. Maybe instead of proxy getting lmtp_client pointer both of them could contain a shared struct lmtp_client_info or something like that. But in any case I'll probably more or less rewrite the whole LMTP code at some point, because I'm planning to implement SMTP submission server and it should share the code with LMTP. (Also I've already written a completely separate tiny SMTP server implementation, which should be merged with both of those. So I guess it needs to become a bit more generic lib-smtp-server.)
On 2012-10-18 12:07 AM, Timo Sirainen <tss@iki.fi> wrote:
I'm planning to implement SMTP submission server and it should share the code with LMTP. (Also I've already written a completely separate tiny SMTP server implementation, which should be merged with both of those. So I guess it needs to become a bit more generic lib-smtp-server.)
Hey Timo,
I hope this means what it sounds like it means...
Can you confirm that this 'submission server' would support the ability to automatically add a copy of all emails sent using it to the designated 'Sent' folder, so that email clients could simply disable the 'Save a copy to Sent folder' feature (that causes the client to upload the message to the server twice, once to send the message, and again to save the Sent copy)?
This is one feature of gmail that I simply love...
Thanks as always,
--
Best regards,
Charles
On 18.10.2012, at 14.22, Charles Marcus wrote:
On 2012-10-18 12:07 AM, Timo Sirainen <tss@iki.fi> wrote:
I'm planning to implement SMTP submission server and it should share the code with LMTP. (Also I've already written a completely separate tiny SMTP server implementation, which should be merged with both of those. So I guess it needs to become a bit more generic lib-smtp-server.)
Hey Timo,
I hope this means what it sounds like it means...
Can you confirm that this 'submission server' would support the ability to automatically add a copy of all emails sent using it to the designated 'Sent' folder, so that email clients could simply disable the 'Save a copy to Sent folder' feature (that causes the client to upload the message to the server twice, once to send the message, and again to save the Sent copy)?
That's not the intended reason for creating it, but easy enough to add as an option, assuming \Sent SPECIAL-USE mailbox is defined.
Anyway, I don't know when I'll actually start implementing it. Mainly just a "would be nice to have some day" thing to support LEMONADE SMTP extensions.
participants (4)
-
Charles Marcus
-
Jack Bates
-
list＠airstreamcomm.net
-
Timo Sirainen