This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project Paul's DBMail tree.
The branch, master has been updated
via 888122ba0e0195bd106a59137764249602bf16b9 (commit)
via
Hi there Paul,
I'd like to ask you permission for something,
Can I write a patch (I'm going to try to do it since I'm not a big C coder),
to:
.. Add an extra field for the dbmail_users table, named last_ip. I
think this is a useful info, aswell the last_login is a very good info, and
Jesse Norell wrote:
That's exactly what dbmail_pbsp does already, just in a separate table.
Maybe you just need to enable pbsp in your config file? (I don't
remember that support being removed, but it's possible. It's still in
the sql schema though.)
The pbsp is only used with the pop3
On Fri, 2009-06-12 at 09:55 -0700, Jonathan Feally wrote:
Jesse Norell wrote:
That's exactly what dbmail_pbsp does already, just in a separate table.
Maybe you just need to enable pbsp in your config file? (I don't
remember that support being removed, but it's possible. It's still in
A better approach to this would probably be a security log table.
user_idnr, service, login_time, logout_time, session_id,
session_status,
ip_address, tcp_port.
This essentially would require a new table, and some db_update calls in
the right places.
Cleaning of this table would be manual
Agreed, that'd be a more useful setup. Also consider marking failed
login attempts (though you might resort to syslog for non-matching
usernames). There have been requests for logging the above as well as
messages/bytes transferred stats and such in the past, I have no idea
where things
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project Paul's DBMail tree.
The branch, master has been updated
via 8dde5d0b07cd1d00d2ba0420db3d866d2148be13 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project Paul's DBMail tree.
The branch, master has been updated
via b0e5f8bf156278f5d159a5f775ce7a371b57c795 (commit)
via
Add migration options to dbmail-util for legacy messageblks
Signed-off-by: Paul J Stevens p...@nfg.nl
---
Paul,
Looking at this, ALL the messages on old table messageblks, HAVE to be
migrated to the new mimeparts correct?
Will this impact something else?
Sorry the questions,
Since I made the patch, I'll comment:
Messages at this point do not have to be moved to the new single storage
structure. Retrieving messages that are not found in the partlists table
will be attempted from the messageblks. This option is there to
convert/move the messages stored with the 2.2.x
Recently we were discussing doing the moves based on a per user basis,
but with some installations of 1000's of users, this seems silly. The
end result is still going to be that you want to move all messages to
the new storage structure. It took about 1.5-2 hours to move 350K
physmessages on
Hum, I have to make some tests after 2.3.5 then, it's always better to
move
I meant, after 2.3.6
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
Here is a preliminary patch.
It adds the dbmail_authlog table
Records the read and write byte counts as well.
Fixes pop3 client bailout process as well.
-Jon
Jorge Bastos wrote:
Agreed, that'd be a more useful setup. Also consider marking failed
login attempts (though you might resort to
13 matches
Mail list logo