- dovecot - dovecot.org

Re: [Dovecot] LDA not being called by postfix?
by Andreas Martin 11 May '06

11 May '06

Hi Luca. Luca Corti schrieb: > On Thu, 2006-05-11 at 15:16 +0200, Andreas Martin wrote: >>> and in the db: >>> >>> +----+-------------+-------------+---------+-----------+----------+-----------+----------+---------------------+---------------------+--------+ >>> | id | domain | description | aliases | mailboxes | maxquota | >>> transport | backupmx | created | modified | >>> active | >>> +----+-------------+-------------+---------+-----------+----------+-----------+----------+---------------------+---------------------+--------+ >>> | 2 | example.com | example.com | 5 | 10 | 20 | >>> virtual | 0 | 2006-05-08 01:30:58 | 2006-05-08 11:42:55 | >> ^^^^^^^ >>> 1 | >>> +----+-------------+-------------+---------+-----------+----------+-----------+----------+---------------------+---------------------+--------+ >> This should be "dovecot" - corresponding to your master.cf: > >>> The transport gets correctly selected upon mail delivery: >> Nope... >> >>> May 11 13:09:47 ns1 postfix/virtual[9797]: 7C4D4847BC: >> ^^^^^^^ >>> to=<luca(a)example.com>, relay=virtual, delay=0, status=sent >> ^^^^^^^ >> >> This should be something like: >> >> May 11 13:09:47 ns1 postfix/pipe[9797]: 7C4D4847BC: >> ^^^^ >> to=<luca(a)example.com>, relay=dovecot, delay=0, status=sent >> ^^^^^^^ > > Now it works... I thought > > virtual_transport = dovecot > > handled this. What is it doing then? Maybe it would work if I didn't > specify the virtual_transport_maps? virtual_transport is the general transport for virtual mailboxes. virtual_transport_maps overrides this to allow you to specify exceptions. Have fun! Andreas

2 1

[Dovecot] mandatory client certificates and crl check in ssl-proxy-openssl.c
by HenkJan Wolthuis 11 May '06

11 May '06

hello, I made a modification to ssl-proxy-openssl.c (patch attached) zo that it a) disconnects when no client certificate is presented b) checks the client certificate against the crl for our root cert. (so you can't use a revoked client cert.) c) returns the CommonName from the client cert. in ssl_proxy_get_peer_name (this way it's easier to use dovecot as imap-proxy with a passwd-like userdb, ssl_require_client_cert and ssl_username_from_cert, it "binds" the emailuser to the clientcertificate, a clientcert. can access only the account from the userdb) in order to use it, the CAfile must be a file which contains the CAcertificate (pem format) followed by the CRL (also in pem format). (servercert and the clientcerts are signed with a self-signed rootcert) there are some issues with the patch: a) it needs openssl > 0.9.7 for the CRL checking b) ssl_verify_client_cert now returns 0 in case of an invalid cert. was there a reason why it always returned 1? c) i'm not too happy with the commonname extraction code, is it secure?? d) i've no experience with programming openssl or dovecot e) i haven't programmed in C for at least 8 years...... does anyone here have more issues, corrections, comments on the patch? can/should this functionality be implemented in dovecot? (conf-file option?) -- groeten, HenkJan Wolthuis --- ssl-proxy-openssl.c.orig 2006-04-04 10:32:58.000000000 +0200 +++ ssl-proxy-openssl.c 2006-05-11 14:08:02.000000000 +0200 @@ -11,6 +11,7 @@ #include <fcntl.h> #include <unistd.h> #include <sys/stat.h> +#include <string.h> #ifdef HAVE_OPENSSL @@ -508,9 +509,42 @@ if (x509 == NULL) return NULL; /* we should have had it.. */ + + // ORIG: X509_NAME_oneline(X509_get_subject_name(x509), buf, sizeof(buf)); + // ORIG: name = t_strndup(buf, sizeof(buf)); + // ORIG: X509_free(x509); + + /* HJHJ get CommonName from peer-certificate */ X509_NAME_oneline(X509_get_subject_name(x509), buf, sizeof(buf)); - name = t_strndup(buf, sizeof(buf)); + + char *tmp; + char *start; + start = buf; + tmp = strstr( buf, "CN=" ); + if( NULL != tmp ) + { + if( strlen(tmp) > 3 ) /* CN= + something */ + { + start = tmp + 3; + tmp = strstr( start, "/" ); + if( NULL != tmp ) /* tmp == NULL: CN is last element in buf */ + { *tmp = '\0'; } + } + else /* empty CN= */ + { + *start = '\0'; + i_warning("get_peer_name empty CN="); + } + } + else + { + *start = '\0'; + i_warning("get_peer_name NO CN="); + } /* CN= not found (no certificate or certificate without commonname??) */ + + name = t_strndup(start, strlen(start) ); X509_free(x509); + /* HJHJ */ return *name == '\0' ? NULL : name; } @@ -582,10 +616,26 @@ proxy = SSL_get_ex_data(ssl, extdata_index); proxy->cert_received = TRUE; + // ORIG: if (!preverify_ok) + // ORIG: proxy->cert_broken = TRUE; + + // ORIG: return 1; + + /* HJHJ */ + char buf[1024]; + X509_NAME_oneline( X509_get_subject_name(ctx->current_cert),buf,sizeof(buf)); + if (!preverify_ok) + { proxy->cert_broken = TRUE; + i_warning("BAD CERT %s: %s",X509_verify_cert_error_string(ctx->error),buf); + } + else + { i_warning("CERT: %s",buf); } - return 1; + return preverify_ok; + /* HJHJ */ + } static int @@ -666,10 +716,20 @@ if (getenv("SSL_VERIFY_CLIENT_CERT") != NULL) { SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_PEER | - SSL_VERIFY_CLIENT_ONCE, + SSL_VERIFY_FAIL_IF_NO_PEER_CERT, ssl_verify_client_cert); } + /* HJHJ */ +#if OPENSSL_VERSION_NUMBER >= 0x00907000L + X509_STORE *store; + if( (store=SSL_CTX_get_cert_store(ssl_ctx)) != NULL ) + { X509_STORE_set_flags( store, X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL); } + else + { i_warning("X509 get cert store failed..."); } +#endif + /* HJHJ */ + /* PRNG initialization might want to use /dev/urandom, make sure it does it before chrooting. We might not have enough entropy at the first try, so this function may fail. It's still been

1 0

[Dovecot] "QUOTA" CAPABILITY keyword advertised incorrectly?
by Mike Brudenell 11 May '06

11 May '06

Greetings - I'm having a frustrating time with mail clients not picking up Dovecot's QUOTA extension to IMAP. The problem is that the QUOTA keyword isn't advertised in Dovecot's response to a CAPABILITY enquiry until *after* the user has authenticated. Unfortunately I've yet to find a mail client that issues a CAPABILITY request after authenticating. Instead all do so upon initial connection to the IMAP server (and, correctly, again after subsequently initiating a STARTTLS session but before authentication). Not re-querying the CAPABILITY after authentication is correct according to the IMAP spec in RFC2060, which says: 6.1.1. CAPABILITY Command Arguments: none Responses: REQUIRED untagged response: CAPABILITY Result: OK - capability completed BAD - command unknown or arguments invalid The CAPABILITY command requests a listing of capabilities that the server supports. The server MUST send a single untagged CAPABILITY response with "IMAP4rev1" as one of the listed capabilities before the (tagged) OK response. This listing of capabilities is not dependent upon connection state or user. It is therefore not necessary to issue a CAPABILITY command more than once in a connection. In particular the last two sentences are relevant. (At present Dovecot is only advertising availability of the QUOTA extension *after* authentication, and hence *is* dependent on the user.) Ths means that at present Dovecot's provision of the QUOTA extension isn't actually getting used by popular mail clients such as Thunderbird. Cheers, Mike Brudenell -- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740 * Unsolicited commercial e-mail is NOT welcome at this e-mail address. *

3 3

[Dovecot] LDA not being called by postfix?
by Luca Corti 11 May '06

11 May '06

Hello, I'm using Postfix with virtual domains (MySQL), Dovecot 1.0beta7 and CVS LDA. I've set up postfix to use the LDA for maildir delivery and defined a global sieve script. -- master.cf -- ... dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -d ${recipient} ... -- main.cf -- smtpd_banner = $myhostname ESMTP append_dot_mydomain = no relayhost = mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all program_directory = /usr/lib/postfix command_directory = /usr/sbin daemon_directory = /usr/lib/postfix mail_owner = postfix soft_bounce = yes message_size_limit = 15728640 biff = no myhostname = mail.example.com mydomain = example.com myorigin = /etc/mailname mynetworks = 127.0.0.0/8 1.2.3.8/29 192.168.0.0/24 mydestination = $myhostname localhost localhost.localdomain alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases local_recipient_maps = proxy:unix:passwd.byname $alias_maps local_transport = local virtual_mailbox_base = /var/vmail virtual_mailbox_domains = proxy:mysql:/etc/postfix/maps/mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:/etc/postfix/maps/mysql_virtual_mailbox_maps.cf virtual_alias_maps = proxy:mysql:/etc/postfix/maps/mysql_virtual_alias_maps.cf proxy:mysql:/etc/postfix/maps/mysql_virtual_mailbox_maps.cf virtual_uid_maps = static:1234 virtual_gid_maps = static:1234 virtual_minimum_uid = 1001 dovecot_destination_recipient_limit = 1 virtual_transport = dovecot relay_domains = proxy:mysql:/etc/postfix/maps/mysql_relay_domains_maps.cf relay_transport = relay transport_maps = proxy:mysql:/etc/postfix/maps/mysql_transport_maps.cf relocated_maps = proxy:mysql:/etc/postfix/maps/mysql_virtual_relocated_maps.cf smtpd_helo_required = yes disable_vrfy_command = yes strict_rfc821_envelopes = yes smtpd_recipient_restrictions = reject_unknown_sender_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client sbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_use_tls = yes smtpd_tls_cert_file = /etc/postfix/smtpd.cert smtpd_tls_key_file = /etc/postfix/smtpd.key content_filter = smtp-amavis:[127.0.0.1]:10024 -- dovecot.conf -- protocols = imap imaps pop3 pop3s ssl_cert_file = /etc/postfix/smtpd.cert ssl_key_file = /etc/postfix/smtpd.key disable_plaintext_auth = no syslog_facility = mail login_greeting = Server ready. default_mail_env = maildir:/var/vmail/%d/%n/Maildir protocol lda { module_dir = /usr/local/lib/dovecot/lda postmaster_address = postmaster(a)example.com global_script_path = /var/vmail/sieve.script auth_socket_path = /var/run/dovecot-auth-master } protocol imap { login_executable = /usr/local/libexec/dovecot/imap-login mail_executable = /usr/local/libexec/dovecot/imap login_greeting_capability = yes imap_client_workarounds = outlook-idle delay-newmail } protocol pop3 { login_executable = /usr/local/libexec/dovecot/pop3-login mail_executable = /usr/local/libexec/dovecot/pop3 pop3_uidl_format = %08Xu%08Xv pop3_client_workarounds = outlook-no-nuls oe-ns-eoh } auth_executable = /usr/local/libexec/dovecot/dovecot-auth auth_default_realm = example.com auth default { mechanisms = plain digest-md5 cram-md5 socket listen { master { path = /var/run/dovecot-auth-master mode = 0660 user = vmail group = vmail } } passdb sql { args = /usr/local/etc/dovecot-sql.conf } userdb static { args = uid=1234 gid=1234 home=/var/vmail/%d/%n/Maildir } } -- sieve.script -- require [ "fileinto" ]; if headers :contains "To" "luca(a)example.com" { fileinto "Spam"; } In my postfix logs I get May 11 00:59:50 ns1 postfix/virtual[9675]: 5E114847BC: to=<luca(a)example.com>, relay=virtual, delay=0, status=sent (delivered to maildir) and the message is there but no filtering is done and the sieve script is not compiled. -- Luca Corti PGP Key ID 1F38C091 Adesso dico: "Amore."

3 11

[Dovecot] Fix for the kevent "Unrecognized event" problem.
by Václav Haisman 11 May '06

11 May '06

The attached patch should fix the problem with dying imap on "Unrecognized event". The problem is that when we register a handle for IO_ERROR only, we still can get readable/writable event without EV_EOF being set. This case was not handled. -- Vaclav Haisman *** ioloop-kqueue.c.~1.4.~ Tue May 2 14:36:56 2006 --- ioloop-kqueue.c Tue May 9 21:29:33 2006 *************** *** 74,80 **** { struct ioloop_handler_context *ctx = ioloop->handler_context; const int fd = io->fd; ! struct kevent ev = { fd, 0, EV_ADD | EV_EOF, 0, 0, NULL }; enum io_condition condition = io->condition & MASK; i_assert(io->callback != NULL); --- 74,80 ---- { struct ioloop_handler_context *ctx = ioloop->handler_context; const int fd = io->fd; ! struct kevent ev = { fd, 0, EV_ADD, 0, 0, NULL }; enum io_condition condition = io->condition & MASK; i_assert(io->callback != NULL); *************** *** 184,190 **** i_assert(ctx->evbuf[i].ident < ctx->fds_size); if ((ctx->fds[ctx->evbuf[i].ident].mode & IO_ERROR) && ! (ctx->evbuf[i].flags & EV_EOF)) { struct io *errio = ctx->fds[ctx->evbuf[i].ident].errio; t_id = t_push(); --- 184,190 ---- i_assert(ctx->evbuf[i].ident < ctx->fds_size); if ((ctx->fds[ctx->evbuf[i].ident].mode & IO_ERROR) && ! (ctx->evbuf[i].flags & (EV_EOF | EV_ERROR))) { struct io *errio = ctx->fds[ctx->evbuf[i].ident].errio; t_id = t_push(); *************** *** 203,216 **** " in I/O handler %p", (void *)io->callback); } } else i_panic("Unrecognized event: kevent {.ident = %u," " .filter = 0x%04x," " .flags = 0x%04x," " .fflags = 0x%08x," ! " .data = 0x%08x}", ctx->evbuf[i].ident, ctx->evbuf[i].filter, ctx->evbuf[i].flags, ! ctx->evbuf[i].fflags, ctx->evbuf[i].data); } } --- 203,224 ---- " in I/O handler %p", (void *)io->callback); } + } else if (ctx->fds[ctx->evbuf[i].ident].mode & IO_ERROR) { + /* + NO-OP. If the handle is registered only for + IO_ERROR, then we can get readable/writable event + but no IO_READ | IO_WRITE set. + */ } else i_panic("Unrecognized event: kevent {.ident = %u," " .filter = 0x%04x," " .flags = 0x%04x," " .fflags = 0x%08x," ! " .data = 0x%08x}\n" ! "mode: 0x%x04x", ctx->evbuf[i].ident, ctx->evbuf[i].filter, ctx->evbuf[i].flags, ! ctx->evbuf[i].fflags, ctx->evbuf[i].data, ! ctx->fds[ctx->evbuf[i].ident].mode); } }

3 6

[Dovecot] IMAP threading - the THREAD command
by Jan Kundrát 11 May '06

11 May '06

Hi folks, there's an extension [1] to IMAP specifying the THREAD command to return list of message sequence numbers grouped to indicate the threading of them. That draft currently defines two algorithms, one of them based solely on Subjects (which is rather dumb) and the second one, combining Subjects with In-Reply-To (etc) headers. The second method is actually advertised and supported by Dovecot. However, I've got quite a lot of friends that lack the knowledge of what the "Subject" field is for, so they just leave it empty. The problem comes when I want Dovecot to return the threads - it follows the ietf draft, so it doesn't check only for references from message headers, but also the subjects. The result is that especially those mails with empty subjects are incorrectly grouped together. So, I'd like to see a feature that would eliminate this problem. It seems to me that there are currently two methods: a) Don't look at the Subject field at all - altough it might increase the speead a bit, it has some disadvantages as well, namely that you'll lose threading if someone uses broken mail client (but broken only in such a way that it preserves subjects) b) Ignore the Subject field if it is empty (after stripping stuff like "re:" etc - just as that draft specifies). Seems reasonable, IMHO. Of course we can't modify the result of a THREAD command (that would break the standard and it generally isn't a proper way to go), so we'd have to introduce another one. I'm pretty sure that especially method a) is very simple (and even simpler if I decided to break the standard by "fixing" the THREAD command), but I really don't like <rant>portable assembler :)</rant> <politely>C</politely>, so are there any chances for this "new and fixed" command to be included into Dovecot? I mean, I might do that in a flawed and ugly way just for me and post a patch so that possible interested persons can pick it, or I migth persuade someone to do it, actually :). Do you think that it's worth the issue? Does anyone have any experiences with talking to the IETF about possible extension of their draft? Ideas? [1] http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.txt Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth

3 4

[Dovecot] Large folders and timeouts
by Fran Fabrizio 11 May '06

11 May '06

I have been having persistent issues with server timeouts on operations on large folders on our Dovecot install (1.0beta2 RPM that came with Fedora Core 5). Some observations from today... I have a Maildir folder with 38,000 messages (it is my Spam folder, naturally :-). In Thunderbird 1.5.0.2, if I click on that folder, it slowly but steadily downloads the headers and after 3-4 minutes, shows me the contents. So far, so good. If I then select all the messages and click Delete to delete them, that operation times out after about 1 minute. If I then click on my Trash folder after some number of minutes has passed, I see that those messages are now both in my Trash and in the original folder - I believe this is because Thunderbird first asks for a COPY over to Trash, and then asks for a STORE +FLAG \\Deleted on the copy that is still in the original folder. It appears that the COPY commands are working but the STORE commands are not since the connection is timing out before they run. I thought I'd try on another mail client, so I tried Squirrelmail. I set it to show 1000 messages per page. It does this just fine. Then I set it to 4,000 messages per page. Then I click on a folder with 12,000 messages, and I get this: ERROR: Connection dropped by IMAP server. Query: SORT (ARRIVAL) ISO-8859-1 ALL My questions are 1. what is the likely cause? and 2. will upgrading to a newer beta address any of this? I'd prefer to wait until FC5 has an updated RPM if possible. Our mail is stored on an NFS store. (I know NFS is slow and that this might be part of the cause.) However, it seems that the timeouts I am having are more related to times when there is no data flowing between the server and client. Note that the timeouts happened when the server was doing a COPY and when the server was doing a SORT but not when the client was downloading 38,000 headers. I'm just at a loss for what to look into next. I don't want to just say "NFS is slow" and live with it if this really has some other cause. :-) So, anyone have any thoughts as to other possible causes? Thunderbird has no option for setting the length of timeout from the client side, so there's nothing I can do from that end. Thanks, Fran -- Fran Fabrizio Senior Systems Analyst Department of Computer and Information Sciences University of Alabama at Birmingham http://www.cis.uab.edu/ 205.934.0653

4 4

[Dovecot] dovecot 1.0beta7 dying on me
by Dave Alden 11 May '06

11 May '06

Hi, Dovecot 1.0 beta7 is dying on me. My logfile shows: May 10 15:54:28 hermes dovecot: IMAP(alden): UIDs broken with partial sync in mbox file /var/mail/alden May 10 15:54:28 hermes dovecot: IMAP(alden): file mbox-sync-rewrite.c: line 106 (mbox_sync_headers_add_space): assertion failed: (start_pos < data_size) May 10 15:54:28 hermes dovecot: child 14185 (imap) killed with signal 6 I'm running this on a RHEL 3U7 system. I created a core file, but it doesn't look like it's too helpful (I've attached the gdb output to this message). I tried recompiling with "--enable-debug", but I got: /usr/lib/mysql/libmysqlclient.a(sha1.o)(.text+0x60): In function `sha1_result': : multiple definition of `sha1_result' ../lib/liblib.a(sha1.o)(.text+0x7f4):/scratch/dovecot-1.0.beta7/src/lib/sha1.c:233: first defined here /usr/bin/ld: Warning: size of symbol `sha1_result' changed from 158 in ../lib/liblib.a(sha1.o) to 126 in ../lib/liblib.a(sha1.o) collect2: ld returned 1 exit status Help? ...dave -- Dave Alden The Ohio State University Department of Mathematics

3 3

[Dovecot] Sieve-Editor
by Andreas Martin 11 May '06

11 May '06

Hi all. I'm looking for an editor for sieve-scripts. I tried the Squirrelmail plugin "avelsieve", but it requires "timsieved", wich Dovecot doesn't use. I don't want my users to write sieve-scripts on the console and server-side-filtering is absolutely required. I know that there are some frontends available, but I can't figure out, which one really works with libsieve and is usable for non-geeks... Do you have any suggestions? Thanks, Andreas

4 5

[Dovecot] pop3 problem with small messages with no Subject: and no To: headers
by Ken A 11 May '06

11 May '06

Hello, Seeing a strange thing with dovecot 1.0 b7 pop3. If a user gets a particular _very_ short spam message (not sure what virus makes these..), with NO Subject and NO To: headers and NO body, (example available upon request), the user is unable to download the mail. The log entry is: May 10 10:51:35 mail dovecot: POP3(user): Disconnected top=0/0, retr=1/1344, del=0/75, size=16383381 There's no QUIT, so no "Logged out" disconnect reason. I did a tcpdump to see what was happening. I have not been able to duplicate this myself yet, even with an exact copy of the message that seems to be causing it, so it could be a client issue, but I've never seen this before, and we just switched to Dovecot, so I thought I'd check with the list.. ideas? Message #9 is requested (it's the one in the user's box with missing headers). Dovecot begins returning it, but then disconnects, or so it seems. 10:51:35.171916 IP customer.60181 > mailserver.pop3: P 40:48(8) ack 1633 win 65535 0x0000: 4500 0030 d326 4000 7106 fc20 4624 16a1 E..0.&@.q...F$.. 0x0010: ceaa 0f11 eb15 006e 7ee7 2a93 d845 fe0c .......n~.*..E.. 0x0020: 5018 ffff 3618 0000 5245 5452 2039 0d0a P...6...RETR.9.. 10:51:35.172177 IP mailserver.pop3 > customer.60181: P 1633:2980(1347) ack 48 win 5840 0x0000: 4500 056b ca0b 4000 4006 3101 ceaa 0f11 E..k..@.@.1..... 0x0010: 4624 16a1 006e eb15 d845 fe0c 7ee7 2a9b F$...n...E..~.*. 0x0020: 5018 16d0 3fde 0000 2b4f 4b20 3133 3237 P...?...+OK.1327 0x0030: 206f 6374 6574 730d 0a52 6574 7572 6e2d .octets..Return- 0x0040: 5061 7468 3a20 3c68 7469 3935 6b67 6576 Path:.<hti95kgev 0x0050: 4072 @r 10:51:35.416549 IP mailserver.pop3 > customer.60181: P 1633:2980(1347) ack 48 win 5840 0x0000: 4500 056b ca0d 4000 4006 30ff ceaa 0f11 E..k..@.@.0..... 0x0010: 4624 16a1 006e eb15 d845 fe0c 7ee7 2a9b F$...n...E..~.*. 0x0020: 5018 16d0 3fde 0000 2b4f 4b20 3133 3237 P...?...+OK.1327 0x0030: 206f 6374 6574 730d 0a52 6574 7572 6e2d .octets..Return- 0x0040: 5061 7468 3a20 3c68 7469 3935 6b67 6576 Path:.<hti95kgev 0x0050: 4072 @r 10:51:35.470688 IP customer.60181 > mailserver.pop3: F 48:48(0) ack 2980 win 64188 0x0000: 4500 0028 d329 4000 7106 fc25 4624 16a1 E..(.)@.q..%F$.. 0x0010: ceaa 0f11 eb15 006e 7ee7 2a9b d846 034f .......n~.*..F.O 0x0020: 5011 fabc 09fa 0000 0000 0000 0000 P............. 10:51:35.470997 IP mailserver.pop3 > customer.60181: F 2980:2980(0) ack 49 win 5840 0x0000: 4500 0028 ca0f 4000 4006 3640 ceaa 0f11 E..(..@.@.6@.... 0x0010: 4624 16a1 006e eb15 d846 034f 7ee7 2a9c F$...n...F.O~.*. 0x0020: 5011 16d0 ede5 0000 P....... 10:51:35.515279 IP customer.60181 > mailserver.pop3: . ack 2981 win 64188 0x0000: 4500 0028 d32e 4000 7106 fc20 4624 16a1 E..(..@.q...F$.. 0x0010: ceaa 0f11 eb15 006e 7ee7 2a9c d846 0350 .......n~.*..F.P 0x0020: 5010 fabc 09f9 0000 0000 0000 0000 P............. That's all, the connection is closed. Ken A Pacific.Net

1 1