Networking wrote:
Strange
Since 2003-12-28 23:59 (using select internal_date from messages;)
my internal_date field is stamping messages at 2004-12-29!!
I've got the same problem too!
Matt
Hi,
I think I've discovered a bug with the crypted passwords if the password is
8 or more characters... Hopefully it's not a bug. Basically, when using a
crypted password, if the correct password is appended with random(any?)
characters, then the user is allowed to login. I'm running the v1.2.1
Jesse Norell wrote:
Hello,
There's no bug there - that's how your crypt() works (and
most traditional crypt() implimentations). That was the single
biggest migration pain when we moved to dbmail; users wrote
down 8 char passwords when they signed up, but typed more than
8 chars into
Matthew T. O'Connor wrote:
On Fri, 2003-10-24 at 03:20, Paul J Stevens wrote:
I for one would vote against having those patches be accepted into
CVS, and I imagine Ilja wont commit them as they are.
Don't get me wrong though; inetd functionality is a valuable
attribute, but I don't think
Matthew T. O'Connor wrote:
I assume these patches are all against CVS (aka 2.0 branch).
No, sorry. 1.2 branch.
The Makefile.concept applies cleanly.
The Makefile.in is using a different version of autoconf, and I'm not sure
how to generate it, or whether just to edit manually.
Assuming the
Ilja Booij wrote:
Problem with using xinetd is that you have to start a new process
every time, which also involves setting up database connections etc,
which cost quite some time.
Indeed, this is the drawback. It's possible with some MySQL setups, that
having the thread_cache set correctly
Matthew T. O'Connor wrote:
In short, just because there can be a performance hit is not a reason
not to allow this functionality into dbmail. I think it would be a
welcome and useful addition.
Try the new code I posted the other day, see subject [Dbmail] ipop3d for
xinetd, it provides this
Matthew T. O'Connor wrote:
I can play with / test it, but I don't normally use pop3, just IMAP.
I would imagine that making imap use xinetd would require almost
identical changes, any chance that can get done?
I'll get on it. Assuming there's not too much difference between pop3 and
imap, it
Matthew T. O'Connor wrote:
I tried to do the same recently. I got everything working except
procmail. RH9 defaults to using sendmail, runs your email through
procmail before delivery, I use this to do all my mail sorting server
side. I couldn't figure out how to use postfix + dbmail +
Matthew T. O'Connor wrote:
Very cool! I'll definitely give it a try when you have the IMAP stuff
going.
I don't use imap, but give this a whirl. I've only tested it to the extent
in setting up an IMAP account in Kmail and it logging on and showing me an
empty inbox.
disclaimer
Use at your own
Chris Mason wrote:
The f in :0fw tells procmail the pipe is a filter, so it expects to
put the resulting output somewhere, instead of thinking the pipe is a
delivery mechanism. Try it without the f.
Also try setting
LOGFILE=$MAILDIR/log and then look at the log file to see where
procmail
Chris Mason wrote:
It seems to have something to do with procmail, I can't reproduce when
inserting the messages manually. Looking harder...
I noticed that you insert messages via dbmail-smtp -m mailbox -u mason,
I've got approx 20 users using procmail to insert their mail with
dbmail-smtp,
Chris Mason wrote:
procmail can do much of this for you, when the dbmail-smtp fails it
falls back to deliver into the default spool file. This gives you
/var/spool/mail/$user
When the database comes back up, run formail -s procmail
/var/spool/mail/$user as each user and things will get
Magnus Sundberg wrote:
I beleive we could drop the sendmail support.
Sure, we could do a popularity vote for each MTA and use only the most
popular one, and drop support for anything else? I don't actually use my MTA
(postfix) to deliver mail to dbmail, I use procmail for each user to call
Hi,
I've currently got 2 servers running a conventional postfix/uw-imapd
solution, and I've been looking to replace this with a more reliable system
in the event of a machine failing.
Having come across dbmail today, I'm impressed so far :-)
But just a quick question..
I plan to have one of
Paul J Stevens wrote:
Sure. Why not. Run a heartbeat-cluster with IP fallover for a mysql
cluster. Use as many different machines as you like, or the same two
machines for that matter, as pop/imap/smtp frontends, all pointing to
the mysql master for their storage backend.
I was just wanting
16 matches
Mail list logo
