[tpop3d-discuss] The way locking in /var/mail works...

[Martin Schmitt]

Hi!

(This was intended for the TPOP3D mailing list, but I'll cc it to
tmda-users, too.)

In addition to regular polling of mail via POP3 through TPOP3D, I use TMDA
to protect myself from SPAM.

TMDA involves two components that run on the server and prefer to
authenticate against a running POP3 daemon. These are tmda-ofmipd, an SMTP
listener that tags outgoing messages according to the rules set in ~/.tmda/
and tmda-cgi, a web-based front-end for TMDA queue management.

My guess at the way they operate is that they connect to the POP3 service
and issue USER and PASS to validate the username/password given, and then
hopefully terminate the session with QUIT. Unfortunately, as Solaris seems
to be a little bit broken, I don't seeem to be able to trace the talk
between the TMDA components and TPOP3D, since they are running on the same
machine and Solaris b0rks when trying to use snoop locally.

However, since I've started using TMDA, I found that my mailbox remains
locked forever in some situations. There's a /var/mail/martin.lock that
just won't go away. I haven't yet been able to willfully reproduce such a
status, but it happens fairly often, like once a week.

I have tried to manually authenticate against TPOP3D and saw that TPOP3D
locks the mailbox immediately after USER/PASS were submitted successfully.
I don't know enough about the implementation of POP3 servers to judge if
that's the right time for locking or not.

Now, my question is: Who is behaving in a "wrong" kind of way here? Does
TPOP3D lock the mailbox too early, or does one of tmda-cgi and tmda-ofmipd
not terminate their POP3-session properly?

If I don't find a direct solution, I can build some kludge to work around
it as the TMDA components support other means of authentication. However,
I'd like to handle it in a "clean" kind of way.

Versions used:

tpop3d   1.4.2
tmda     0.77
tmda-cgi 0.07

Any input will be greatly appreciated.

Thanks all,

-martin

-- 
49. YEEEHA!!! What a CRASH!!!
                      -- Top 100 things you don't want the SysAdmin to say