11:33 p.m.
It is time for me to migrate my mail system to FC3. It is a RH9 system
running sendmail/procmail and UW-imapd. I don't see any compelling
reason to change sendmail/procmail but the lack of support for uw-imapd
is pretty compelling to switch the IMAP server. The tenor of the mail
archives seems to point to dovecot as the IMAP server of choice for
someone like myself who is running a small shop and wants to have a
secure, simple and supported (out of the box, so to speak) solution.
The cyrus solution comes in a very close second.
The dovecot wiki has good support documentation for the migration but
before I jump in I'd like to get some opinions from people on this list
on what to watch out for, etc. that will make the migration as smooth as
possible.
As near as I can tell, it looks like all I need to do is save the
current sendmail configuration, the current /var/spool/mail/* files,
install FC3 fresh, restore the sendmail config and /var/spool/mail/*
files, enable and configure dovecot per the wiki migration notes and
then reconnect the system to the net. And it will work like a charm. :-)
I use TDMA for spam control now but would love to hear opinions on why I
should either keep TDMA or switch to spamassasin from those who have
faced that decision.
Thanks,
-pmr
11:48 a.m.
Am Mo, den 29.11.2004 schrieb Paul Michael Reilly um 6:33:
It is time for me to migrate my mail system to FC3. It is a RH9
system
running sendmail/procmail and UW-imapd. I don't see any compelling
reason to change sendmail/procmail but the lack of support for uw-imapd
is pretty compelling to switch the IMAP server. The tenor of the mail
archives seems to point to dovecot as the IMAP server of choice for
someone like myself who is running a small shop and wants to have a
secure, simple and supported (out of the box, so to speak) solution.
The cyrus solution comes in a very close second.
Yes, for a small up to middle size mail server (POP3/IMAP) dovecot
should be the choice. Especially if you was satisfied so far with the
uw-imapd.
The dovecot wiki has good support documentation for the migration but
before I jump in I'd like to get some opinions from people on this list
on what to watch out for, etc. that will make the migration as smooth as
possible.
Work with backups made first! In this case you don't risk any data loss
either which faults might happen.
Here on the list I did only read 1 or 2 postings where people reported
problems with the Outlook mail client: for some mail users all was fine
after migration, for others not. IIRC it is a known Outlook bug.
As near as I can tell, it looks like all I need to do is save the
current sendmail configuration, the current /var/spool/mail/* files,
install FC3 fresh, restore the sendmail config and /var/spool/mail/*
files, enable and configure dovecot per the wiki migration notes and
then reconnect the system to the net. And it will work like a charm. :-)
The changes from Sendmail 8.12 (RH9) to Sendmail 8.13 (FC3) aren't that
big. So you should be able to keep the sendmail.mc as it is. Just be
sure that a "make -C /etc/mail" will not spit out any errors on the FC3
system.
Keep care to preserve the UIDs/GIDs of your system user accounts. Else
you will have to change ownerships by hand on the spool mboxes.
Yes, following all advices from the dovecot Wiki will bring you safe
from point A to point B.
I use TDMA for spam control now but would love to hear opinions on
why I
should either keep TDMA or switch to spamassasin from those who have
faced that decision.
You run a web shop and use a Challenge/Response system for mailing? This
is practical?
I have very good experience by running Sendmail along with ClamAV-milter
(anti-virus protection) and SpamAssassin (spam classification, bound to
Sendmail using MimeDefang). milter-spamc is too a very good tool to
integrate SA into SM mail stream.
-pmr
Alexander
--
Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp
Serendipity 18:48:23 up 9 days, 13:35, load average: 0.05, 0.23, 0.26
12:17 p.m.
Alexander Dalloz wrote:
Am Mo, den 29.11.2004 schrieb Paul Michael Reilly um 6:33:
...
>I use TDMA for spam control now but would love to hear opinions on
why I
>should either keep TDMA or switch to spamassasin from those who have
>faced that decision.
You run a web shop and use a Challenge/Response system for mailing? This
is practical?
No to both: I do not run a web shop and a challenge/response system is
not practical. It did a great job at pruning incoming spam but put off
a number of people, mail lists and organizations. So I am looking for a
better solution.
I have very good experience by running Sendmail along with
ClamAV-milter
(anti-virus protection) and SpamAssassin (spam classification, bound to
Sendmail using MimeDefang). milter-spamc is too a very good tool to
integrate SA into SM mail stream.
I may try this approach. If you have a reference that would be useful.
If not, I'll google ClamAV-milter and milter-spamc. I've not heard of
these before. Thanks for your input. What is SA and SM?
-pmr
12:52 p.m.
Am Mo, den 29.11.2004 schrieb Paul Michael Reilly um 19:17:
> You run a web shop and use a Challenge/Response system for
mailing? This
> is practical?
No to both: I do not run a web shop and a challenge/response system is
not practical. It did a great job at pruning incoming spam but put off
a number of people, mail lists and organizations. So I am looking for a
better solution.
Ok :) Then I misunderstood you. I took your sentence "someone like
myself who is running a small shop and wants to have a" as if you would
run this shop online. So I was surprised about the C/R statement. Please
don't mind.
> I have very good experience by running Sendmail along with
ClamAV-milter
> (anti-virus protection) and SpamAssassin (spam classification, bound to
> Sendmail using MimeDefang). milter-spamc is too a very good tool to
> integrate SA into SM mail stream.
I may try this approach. If you have a reference that would be useful.
If not, I'll google ClamAV-milter and milter-spamc. I've not heard of
these before. Thanks for your input. What is SA and SM?
http://www.fedoranews.org/contributors/ron_goulard/clamav
once written for FC1, but still valid in basics (btw. I am using the
http://crash.fce.vutbr.cz/crash-hat/3/clamav/ packages on my FC mail
servers)
http://www.milter.info/milter-spamc/index.shtml
if problems/questions occur feel free to ask
SA stands for SpamAssassin
SM stands for (no, not sado-maso :) SendMail
-pmr
Alexander
--
Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp
Serendipity 19:51:52 up 9 days, 14:39, load average: 0.63, 0.54, 0.47
12:19 a.m.
Alexander Dalloz wrote:
Am Mo, den 29.11.2004 schrieb Paul Michael Reilly um 6:33:
...
>As near as I can tell, it looks like all I need to do is save the
>current sendmail configuration, the current /var/spool/mail/* files,
>install FC3 fresh, restore the sendmail config and /var/spool/mail/*
>files, enable and configure dovecot per the wiki migration notes and
>then reconnect the system to the net. And it will work like a charm. :-)
The changes from Sendmail 8.12 (RH9) to Sendmail 8.13 (FC3) aren't that
big. So you should be able to keep the sendmail.mc as it is. Just be
sure that a "make -C /etc/mail" will not spit out any errors on the FC3
system.
Keep care to preserve the UIDs/GIDs of your system user accounts. Else
you will have to change ownerships by hand on the spool mboxes.
Yes, following all advices from the dovecot Wiki will bring you safe
from point A to point B.
I think something has changed to tighten the constraints on UID values
below 500. I have accounts with UIDs below 500 who are not receiving
mail whereas others are. Can you point me at some explanation for this
behavior and recommended remedies?
Thanks,
-pmr
1:08 p.m.
Am Mo, den 06.12.2004 schrieb Paul Michael Reilly um 7:19:
> Keep care to preserve the UIDs/GIDs of your system user
accounts. Else
> you will have to change ownerships by hand on the spool mboxes.
> Yes, following all advices from the dovecot Wiki will bring you safe
> from point A to point B.
I think something has changed to tighten the constraints on UID values
below 500. I have accounts with UIDs below 500 who are not receiving
mail whereas others are. Can you point me at some explanation for this
behavior and recommended remedies?
-pmr
Paul,
I am not sure whether I understand you correctly. You say your system
has created user accounts with UID below 500? I guess you created user
account in that UID area, right? Correct me if I am wrong. And you are
saying that you have accounts which should be able to receive mail while
they don't? Maybe I understand you better if you rephrase a bit what you
mean and give some real world examples from your host(s).
freshrpms.net has a page which lists UIDs used on Redhat / Fedora
systems:
http://freshrpms.net/packages/res/uidgid.html
Other Linux distributions handles UID numbers differently.
Alexander
--
Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp
Serendipity 19:57:22 up 19:19, 17 users, 1.18, 1.08, 1.20
10:40 p.m.
Alexander Dalloz wrote:
Am Mo, den 06.12.2004 schrieb Paul Michael Reilly um 7:19:
>>Keep care to preserve the UIDs/GIDs of your system user accounts. Else
>>you will have to change ownerships by hand on the spool mboxes.
>>Yes, following all advices from the dovecot Wiki will bring you safe
>>from point A to point B.
>
>I think something has changed to tighten the constraints on UID values
>below 500. I have accounts with UIDs below 500 who are not receiving
>mail whereas others are. Can you point me at some explanation for this
>behavior and recommended remedies?
>-pmr
Paul,
I am not sure whether I understand you correctly. You say your system
has created user accounts with UID below 500? I guess you created user
account in that UID area, right? Correct me if I am wrong. And you are
saying that you have accounts which should be able to receive mail while
they don't? Maybe I understand you better if you rephrase a bit what you
mean and give some real world examples from your host(s).
My apologies for a red herring (aka wild goose chase). I found out what
was really wrong. FWIW, a group of low numbered (UID) users all had
TMDA set up and after the re-install, the TMDA setup tried to run TMDA
but it was not installed so the delivery failed. The logging
information was rather sparse so it took me a while to figure out what
was happening. It appeared as though only users with UID values below
500 were the only ones not getting mail. This was pure coincidence, as
it turns out.
No I'm ready to integrate mimedefang. Do you have a URL handy that I
can use as a guide for my sendmail/procmailrc configuration?
Thanks,
-pmr
11:29 p.m.
On Tuesday 07 December 2004 12:40, Paul Michael Reilly wrote:
No I'm ready to integrate mimedefang. Do you have a URL handy
that I
can use as a guide for my sendmail/procmailrc configuration?
Did you check Roaring Penguin?
Mimedefang uses milter. I don't think procmail is involved.
--
Cheers
John Summerfield
tourist pics: http://environmental.disaster.cds.merseine.nu/
11:05 p.m.
On Mon, 2004-11-29 at 00:33, Paul Michael Reilly wrote:
I use TDMA for spam control now but would love to hear opinions on
why I
should either keep TDMA or switch to spamassasin from those who have
faced that decision.
I would recommend you implement greylisting in addition to either TDMA
or spamassassin. I started out using spamassassin which worked very
well. But I found that it still cost considerable time reviewing tagged
messages for false positives. As such I implemented greylisting which
reduced the number of spam messages from 3000 to 6000 a day to 5 to 10 a
day. It worked so well that virtually no time is spent on spam
anymore. I used sendmail with the milter-greylist milter. There are
several different versions out there with different features. I liked
the milter-greylist implementation since it used a berkely DB instead of
a MYSQL which a different package used. That seemed to be over kill
IMHO.
It probably depends on the volume of email you are handling and if you
need to implement fail overs and other things.
--
Scot L. Harris
webid(a)cfl.rr.com
... I'm IMAGINING a sensuous GIRAFFE, CAVORTING in the BACK ROOM
of a KOSHER DELI --
7091
days inactive
7099
days old
8 comments
4 participants
participants (4)
-
Alexander Dalloz -
John Summerfield -
Paul Michael Reilly -
Scot L. Harris