--On Thursday, January 29, 2004 11:16 PM +0200 Timo Sirainen tss@iki.fi wrote:
I don't yet really even want Dovecot to be too well known, it's not ready yet. When 1.0 comes (this spring I hope) I'll start publicizing it more. After that I should only need to add new features - existing ones should be perfect and better than anyone else's ;)
Just a heads-up, then.
A regular FAQ on the SA-Talk list is how to integrate SA into someone's IMAP/POP3 server, and once Dovecot gets popular, you'll start seeing that question here.
I run SA from sendmail via MIMEDefang (to reject the egregious stuff), and from procmail on delivery (to tag and quarantine the borderline stuff). I'm not sure why people would use it in the IMAP server, but the question does come up.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 29 January 2004 01:28 pm, Kenneth Porter wrote:
--On Thursday, January 29, 2004 11:16 PM +0200 Timo Sirainen tss@iki.fi
wrote:
I don't yet really even want Dovecot to be too well known, it's not ready yet. When 1.0 comes (this spring I hope) I'll start publicizing it more. After that I should only need to add new features - existing ones should be perfect and better than anyone else's ;)
Just a heads-up, then.
A regular FAQ on the SA-Talk list is how to integrate SA into someone's IMAP/POP3 server, and once Dovecot gets popular, you'll start seeing that question here.
I run SA from sendmail via MIMEDefang (to reject the egregious stuff), and from procmail on delivery (to tag and quarantine the borderline stuff). I'm not sure why people would use it in the IMAP server, but the question does come up.
well I don't use it directly from the imap persay but here is most likely why. I use postfix, dovecot and maildrop. With this setup you can have you email filtered for you so when you log into your imap account it is already filtered and were everything should go. I also in my case have maildrop setup to do the spam and virii filtering. This comes in handy for being able to let the users adjust their own email settings. All this also ties in perfectly with squirrelmail which I have running on top of dovecot also.
-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~- Brook Humphrey Mobile PC Medic, 420 1st, Cheney, WA 99004, 509-235-9107 http://www.webmedic.net, bah@webmedic.net, bah@linux-mandrake.com Holiness unto the Lord -~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-~'~-~
'~-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAGYA3nT1TkA6FgPgRAgdMAJ4weSCQHLURcfASR/O+nU+R4J1ETgCeMG1N 0ASbIGNXvDtm/s6QoM/qww0= =SJH6 -----END PGP SIGNATURE-----
Kenneth Porter wrote:
I run SA from sendmail via MIMEDefang (to reject the egregious stuff), and from procmail on delivery (to tag and quarantine the borderline stuff). I'm not sure why people would use it in the IMAP server, but the question does come up.
SA is more appropriate at the MTA level, not the MDA/MUA level. I'm not sure why it would come up either. It's generally called from Procmail or someplace like that.
-Rick
-- Rick Johnson, RHCE #807302311706007 - rjohnson@medata.com Linux/Network Administrator - Medata, Inc. PGP Public Key: https://mail.medata.com/pgp/rjohnson.asc
Rick Johnson wrote:
Kenneth Porter wrote:
I run SA from sendmail via MIMEDefang (to reject the egregious stuff), and from procmail on delivery (to tag and quarantine the borderline stuff). I'm not sure why people would use it in the IMAP server, but the question does come up.
SA is more appropriate at the MTA level, not the MDA/MUA level. I'm not sure why it would come up either. It's generally called from Procmail or someplace like that.
I concur. Filtering for spam belongs before the local delivery agent. Of course, I complicate things with the hybrid sender-pays system and need to grab "outbound" e-mail messages for stamping. Let's just say it makes for an interesting mail server configuration.
---eric
-- Speech recognition in use. Incorrect endings, words, and case is closer than it appears
On Thu, Jan 29, 2004 at 05:03:09PM -0500, Eric S. Johansson wrote:
Rick Johnson wrote:
SA is more appropriate at the MTA level, not the MDA/MUA level. I'm not sure why it would come up either. It's generally called from Procmail or someplace like that.
Isn't that a contradiction? procmail is most often used at the delivery level, although sometimes it's used for system-wide pre-filtering. But I tend to think of procmail as LDA (local delivery agent), so if you call spamassassin out of procmail, it's acting on behalf of the LDA.
I concur. Filtering for spam belongs before the local delivery agent.
I disagree/agree. While I believe there's room for spam filtering at more than one point in the chain, it seems to me it's appropriate at the LDA level on a per-user basis. Now, if you're saying that it's better to solve the spam problem so that it never gets to the LDA point, yes, that would be wonderful. But in a world where spam does reach the end user, filtering at final delivery is appropriate.
Of course, I complicate things with the hybrid sender-pays system and need to grab "outbound" e-mail messages for stamping. Let's just say it makes for an interesting mail server configuration.
Ah well, I have my own bias too :-). I have a utility that incorporates a combination SIEVE/C delivery language. Since I use as an LDA (among other places) I obviously believe filtering is appropriate there.
mm
On Fri, 2004-01-30 at 00:49, Mark E. Mallett wrote:
Ah well, I have my own bias too :-). I have a utility that incorporates a combination SIEVE/C delivery language. Since I use as an LDA (among other places) I obviously believe filtering is appropriate there.
I've still not gotten around trying your sieve thingy. Any chance of getting some simple Postfix/maildir mini-howto? :)
On Fri, Jan 30, 2004 at 01:06:37AM +0200, Timo Sirainen wrote:
On Fri, 2004-01-30 at 00:49, Mark E. Mallett wrote:
Ah well, I have my own bias too :-). I have a utility that incorporates a combination SIEVE/C delivery language. Since I use as an LDA (among other places) I obviously believe filtering is appropriate there.
I've still not gotten around trying your sieve thingy.
I mentioned it before, I think, but I hadn't really provided a way to get at it until just this month.
Any chance of getting some simple Postfix/maildir mini-howto? :)
It's in a fairly raw state: quite usable, but still specific to my own use, and many things still just a twinkle in the eye (you have to use your imagination for some of them). I have a download area for any software types who are willing to put up with that. However I'd be happy to have people try it and help kick me along.
Anyway, without co-oping your list further..
http://www.mv.com/tools/mvmf/test/
I run it under qmail but have compiled in sendmail and postfix environments (invoked out of a .forward or .procmailrc), and there is a USING file with some specifics about those things.
mm
Looking at the possible LDAP passwords Schemes, if I wanted to use PLAIN-MD5 or DIGEST-MD5, what would format would I use in LDAP for the userPassword field ? I have done SHA, SSHA, and MD5 before, but not sure what is acceptable for the above mentioned, that dovecot can use.
Thanks
On Sat, 2004-01-31 at 01:21, SAiello@Jentoo.com wrote:
Looking at the possible LDAP passwords Schemes, if I wanted to use PLAIN-MD5 or DIGEST-MD5, what would format would I use in LDAP for the userPassword field ? I have done SHA, SSHA, and MD5 before, but not sure what is acceptable for the above mentioned, that dovecot can use.
PLAIN-MD5 means the field contains just the MD5 sum of the password in hex. DIGEST-MD5 is MD5 sum of user:realm:password string. They don't have any special format in there..
On Mon, Feb 02, 2004 at 08:02:53PM +0200, Timo Sirainen wrote:
On Sat, 2004-01-31 at 01:21, SAiello@Jentoo.com wrote:
Looking at the possible LDAP passwords Schemes, if I wanted to use PLAIN-MD5 or DIGEST-MD5, what would format would I use in LDAP for the userPassword field ? I have done SHA, SSHA, and MD5 before, but not sure what is acceptable for the above mentioned, that dovecot can use.
PLAIN-MD5 means the field contains just the MD5 sum of the password in hex. DIGEST-MD5 is MD5 sum of user:realm:password string. They don't have any special format in there..
There is a certain impedence mismatch between RFC2307's idea of {MD5} and Dovecot's. I tinkered a while ago with this quirk and the resulting patch is attached. (also available from http://www.roughtrade.net/dovecot/)
Caveat emptor: it is totally untested beyond my workstation, it is unchanged from months ago, has not been reviewed by Timo and is not in the CVS tree. I've only just confirmed that it compiles with 0.99.10.4. Let me know if it's of any use.
Regards Joshua.
-- Joshua Goodall "as modern as tomorrow afternoon" joshua@roughtrade.net - FW109
participants (8)
-
Brook Humphrey
-
Eric S. Johansson
-
Joshua Goodall
-
Kenneth Porter
-
Mark E. Mallett
-
Rick Johnson
-
SAiello@Jentoo.com
-
Timo Sirainen