Topic: Mail

[Colin Mattoon]

I'm fairly certain this has been covered before, but I didn't find a case that I could recognize as sufficiently similar to mine in either the manual, or the forum, to answer my question.

My situation is: Slow internet connection (semi-rural area -- I can't get a better connection until 4th quarter of this year -- if then).  Dialup ISP with multiple mail accounts on their pop3 server. Dynamic address assigned by ISP, no registered domain name. Running e-smith 3.0.

ISP is unwilling to setup a mail spool even if I want to register domain name and do the "ETRN" thing.  I could switch ISP's, but their competitors are all running NT servers and suffer regular service outages.

We regularly recieve e-mail with attachments that are several megabytes, even when zipped.  Often, these must then be forwarded to another company. Takes forever.

By specifying my e-smith server as the smtp server, the time spent sending mail from a workstation is greatly reduced. For example, using Pine from a Linux or Unix box to send a large e-mail will tie up the workstation for several minutes just to contact the ISP's smtp server. When I use e-smith as smtp server, it takes a couple of seconds to transmit mail and then e-smith can fight with the ISP as long as it needs to. Works great.

My problem is, when I get to the office this morning, I'll have at least 180 messages to download, for my account alone.  Obviously, since I have Linux on my workstation, I could setup fetchmail on the workstation to run as a cron job like I did at home. Problem is, I'm not the only one who gets this volume of mail and some workstations run Win98. I don't want to leave them on all the time, checking the ISP's pop3 server for mail every 10 minutes.

So, the question(s) is/are:

Is it possible/practical to set up .fetchmailrc and crontab -e on e-smith for each user (no more than a dozen) and then point each mail client on the workstations at that particular user's account on the e-smith server as the pop3 mail server?  (I don't want mail clients on the e-smith [like PINE run through a telnet session]...I want to flush the mail out to the workstations, when they request it).

And, if so, where can I read up on it? Or, if not possible, any alternate suggestions?

Thanks,

Colin

[Dan Brown]

Colin Mattoon wrote:

> Is it possible/practical to set up .fetchmailrc and crontab -e on e-smith for each
> user (no more than a dozen) and then point each mail client on the workstations
> at that particular user's account on the e-smith server as the pop3 mail server?

    I don't know about the cron bit (I'd be interested in hearing about it), but it should be possible to set up fetchmail to grab this mail.  The way I've done it, which probably isn't the cleanest, but works, is to make a single .fetchmailrc file in /root containing the relevant account information, and set "daemon 300" to make it poll every 5 minutes.  Works pretty well for me, and eliminates the need for a cron job.

[Colin Mattoon]

You put all the users that need this service under one fetchmailrc as root?  I never thought of that. Well, actually, I didn't realize it was possible...I just assumed one user per fetchmailrc file and one fetchmailrc file in each user account was the only way...but I may have to try this...

So do you just configure each workstation to look at e-smith's /var/spool/mail as pop3, or what?

Thanks

COLIN

[Dan Brown]

Colin Mattoon wrote:

> You put all the users that need this service under one
> fetchmailrc as root?  I never thought of that. Well, actually,
> I didn't realize it was possible...I just assumed one user per

    To be honest, I haven't gone this far yet; I've only used one user.  From what I've read in the fetchmail docs, though, I don't see any reason why you shouldn't be able to have multiple users in the same .fetchmailrc.  The key would be to do something like this in .fetchmailrc:

poll mail.myisp.net proto POP3
user remoteuser1 is localuser1@localhost.localdomain
pass remotepass1

poll mail.myisp.net proto POP3
user remoteuser2 is localuser2@localhost.localdomain
pass remotepass2

etc.

    It's important to include your e-smith machine's full domain name in the "user" statements.  It seems that you should be able to give just the usernames--but when you do that, fetchmail tries to deliver messages to user@localhost, which the e-smith box bounces (or at least mine does).  I don't know why this is.

> So do you just configure each workstation to look at e-smith's
> /var/spool/mail as pop3, or what?

    I configure client machines to connect to the e-smith box via POP3 or IMAP (I've installed the IMAP server to be able to use the IMP webmail system).  It works quite nicely.

[Charlie Brady]

Dan Brown wrote:

> Colin Mattoon wrote:
>
> > You put all the users that need this service under one
> > fetchmailrc as root?  I never thought of that. Well,
> actually, > I didn't realize it was possible...I just
> assumed one user per

I'd rather that it was done per user. Having it per user is a start towards putting it under the users' control. Once we have a template which works, we can create a user screen so that we can allow users to set up fetching from external POP accounts, just as they can change their own password, without needing the intervention of the system administrator.


> It's important to include your e-smith machine's full domain
> name in the "user" statements.  It seems that you
> should be able to give just the usernames--but when you do
> that, fetchmail tries to deliver messages to user@localhost,
> which the e-smith box bounces (or at least ....

I consider that a bug in fetchmail. It's reasonable for it to default to using localhost as its SMTP server, but it should then pass on the messages with recipient address of "user", not "user@localhost".

Charlie

[Roald Opsahl]

Can't really see that the single fetchmail file is a problem if we want users to themselves request that mail is picked up. After all, when a user changes his password we rewrite a shared file, the same method could be used for the fetchmail file.

That way the administrator would control when and how often we fetch mail, the users would control which accounts we pick up from. A fair way to share the responsibilities in my opinion. Only problem would be to remember to remove the users entries from that file when we remove a user. That would of course be easier using the distributed approach, there the file would go away the moment we removed the home directory. I generall think that the distributed version is more suited to machines where the user has shell access to the machine, he would then be able to finetune all kinds of settings.

If we really want to be fancy we could allow for both, I still think the shared should be the default.

[Charlie Brady]

Roald Opsahl wrote:

> Can't really see that the single fetchmail file is a problem if

This discussion really belongs on the developer mailing list. I'll repost it there, so others can hear the story.

You make some valid points, but I still tend towards having seperate crontab jobs.

Cheers

Charlie

[Colin Mattoon]

Thanks, guys...looks like I have me a little project for this weekend!

Colin