Hi there

so I got naughty again and wanted to do something extraordinary - use fetchmail to retrieve POP mail. This seemed to require me to get an smtp server running. On Mandrake 9.1 by the way. It appeared like I needed something called postfix. So far so good.

Judging from its verbose output, fetchmail for all I can see seems to work well - but forwarding the mail it retrieves to the brand new local SMTP server proved to be a fatal mistake - any mail sent there falls into a black hole. So it appears all mail sent to any of my POP accounts today is now lost.

"philip" is one of the users on my machine. So I figured, "mail philip@my.dyndns.org" should produce a "You have new messages in /var/spool/mail". It did no such thing. Yet here's the syslog, which, from the looks of it, may be interesting.

Jan 2 18:32:43 fuchur postfix/cleanup[20761]: 88D0C30401: message-id=<20040102233243.88D0C30401@my.dyndns.org>
Jan 2 18:32:43 fuchur postfix/nqmgr[18808]: 88D0C30401: from=<>, size=2059, nrcpt=1 (queue active)
Jan 3 00:32:43 fuchur kernel: grsec: From 192.168.1.2: attempted resource overstep by requesting 62752218 for RLIMIT_FSIZE against limit 51200000 by (procmail:23605) UID(501) EUID(501), parent (local:20022) UID(0) EUID(73)
Jan 3 00:32:43 fuchur kernel: grsec: From 192.168.1.2: attempted resource overstep by requesting 62752218 for RLIMIT_FSIZE against limit 51200000 by (procmail:23605) UID(501) EUID(501), parent (local:20022) UID(0) EUID(73)
Jan 3 00:32:43 fuchur postfix/local[20022]: 88D0C30401: to=<philip@my.dyndns.org>, orig_to=<root@my.dyndns.org>, relay=local, delay=0, status=bounced (can't create user output file. Command output: procmail: Error while writing to "/var/spool/mail/philip" )
Jan 3 00:32:49 fuchur imapd[17439]: Logout user=philip host=dell [192.168.1.2]

(Machine name and dyndns account name changed)
(Putting the above in CODE tags seems to prevent appropriate line breaks, making this a pain to read)

Changing permissions of all files in /var/spool/mail to 777 didn't do any good.

As you can probably tell by now, including my inability to set up a widely-used SMTP server, I have never done this before and am stumped. Will appreciate any pointers in the right direction.

Thanks in advance,
Philip

Erm, you're doing something disasterously wrong. Fetchmail does not require a local SMTP server. Why would you not choose to deliver mail to your mbox or maildir in your home directory? You need to re-read the fetchmail documentation.

The only reason to have Postfix would be to receive SMTP mail from the outside (i.e. if you were hosting your own domain).

If you get scared about fiddling around with config files [or just generally confused], then get webmin [ www.webmin.com ] which is an excellent tool for configuring stuff via a web browser. Immensely easy to install to, no apache setup needed

First of all, thanks for the replies.

man fetchmail is what got the whole SMTP story started ..

"As each message is retrieved fetchmail normally delivers it via SMTP to
port 25 on the machine it is running on (localhost), just as though it
were being passed in over a normal TCP/IP link. The mail will then be
delivered locally via your system's MDA (Mail Delivery Agent, usually
sendmail(8) but your system may use a different one such as smail,
mmdf, exim, or qmail). All the delivery-control mechanisms (such as
.forward files) normally available through your system MDA and local
delivery agents will therefore work.

If no port 25 listener is available, but your fetchmail configuration
was told about a reliable local MDA, it will use that MDA for local
delivery instead. At build time, fetchmail normally looks for exe-
cutable procmail(1) and sendmail(1) binaries."

Since "MDA" sounded even more scary to me than yet another process ending in "d", I figured "how hard can it be to wait for incoming mail on port 59 (which is btw. still stealthed to the outside world). (@pnh73: thank you for the hint, but this is also supposed to be a learning experience, which is why I've been trying to steer clear of webmin and the likes if I could afford it. And, don't ask me how but I *am* running a working Apache server among others on that machine.)

But it appears that I can not, this time, afford to leave anything unattempted in getting fetchmail to actually deliver. The fetchmail manpage has not brought me any closer, even the promising-looking "-m" option seems to rely on sendmail and procmail.

"-m <command> | --mda <command>
(Keyword: mda) You can force mail to be passed to an MDA
directly (rather than forwarded to port 25) with the --mda or -m
option. (...)"

So I'm still open for any viable solution. I really don't need the SMTP server. I would just like anything that can download mail from POP3 accounts to the native linux /var/spool/mail. Or a procmail that doesn't generate strange-looking error messages in the syslog, all the while deleting any mail it gets. One would think that'd be feasible, right?

Cheers,
Icarus

Hello? Now you're either ignoring me because my problems seem too easy for you or everyone considers this case closed .. it isn't. My proposal to introduce some kind of ticketing system - heck, just a flag people can set on threads to show whether they were done or not, was declined months ago.

So here I am again trying to get a little attention. I do *not* think I'm entitled to this, yet I am convinced there are people capable of handling fetchmail on this board who can give me a hint in less than 30 seconds.

I thank thee in advance.

May this be any use:

http://www-dt.e-technik.uni-dortmund...fetchmail.html

Does /var/spool/mail/philip exist? Doesn't look like it. That may be your problem.

Fetchmail retrieves your mail and gives it to Postfix. As usual, it seems you have it set up for Postfix to then hand the mail off to procmail. However procmail can only deliver mail to mboxes that already exist.

/var/spool/mail/philip should be a file, not a directory. I'm not sure how you create your spool mbox; starting an old school unix mail program (mutt or elm) should create it for you. Then try again.

Your primary problem is deleting mail from your server before working the kinks out of your mailsystem. You should configure fetchmail to leave the mail on the server until it's all worked out. You should add this line to your .fetchmailrc: keep.

Thanks again for the replies.

pnh: That page seems to be dealing with bugs in fetchmail < 7.5.9, I am running 6.2.1.

mac_phil:
I might have mentioned that I have up until now been using OpenWebmail, which has been doing the POP3 for me. But now I figured it'd be nice to have a daemon that does that periodically, even without me being logged into OWM.

So that's where the trouble started.

As you can see, the permissions of /var/spool/mail/philip should not be the issue.

Thanks again for any pointers, regards,
Icarus

Holy cow dude, do you really want 1777 on every mbox? I highly doubt that...

By the way, it would have been nice if you had mentioned OWM in the first place, because that may be doing other weird things with your mail, like moving it to a different directory that OWM uses or something like that.

Oh, and additionally if you refer back to the original error messages you will see that grsec is preventing procmail from writing to the mail spool. Perhaps you should inivestigate that before assuming it's a problem with the e-mail applications themselves? Procmail is only telling you what happened (couldn't write to the file), but that wasn't an error on procmail's part--it was prevented from writing by grsec.

And one last thing, what are you talking about "port 59" for? That doesn't even appear in /etc/services.

Hi, erm, dude, thanks for taking the time.

Not that someone breaking into this box and doing evil things with my mail is something that makes me lose sleep, but you're right, I don't want 1777 on every mailbox. But that was one of the first things I tried when they apparently couldn't be written to. And I was going to leave it like that until, if ever, the issue is resolved.

Sorry about not mentioning OWM, that was my bad, just like mixing up port 25 and 59, I was tired and spending too much time on IRC I guess. I can confirm that OWM does not remove any mail from the original directory, since /var/spool/mail/philip contains all mail up to the most recent one.

On to the grsec thing. See, I had no idea that this syslog entry meant that grsec was the problem. I followed your suggestion and tried to "investigate" that, but it apparently is not a process but a "kernel module". Now while I may have a rough draft of an idea what that could mean, I surely don't know what to do if one of those bad boys chooses to keep procmail from working.

But apparently this really isn't so much of a "simple" problem, I thought it's one of those "oh yeah it can't work unless you change that 0 to a 1" kind of situations. Seems I would have to read a whole lot of documentation and manuals before I can hope to have fetchmail deliver anything to my hard drive. While I would love to do that, with the amount of leisure I get these days, it's just not happening. So maybe it's just not for me.

Thanks anyway for trying.

Lets make this easy: run postconf -n and post the results here. That will give us an idea what the postfix part of this is doing. Sounds like its trying to deliver to non existent mail boxes. If you post it here I can help. I have built plenty of postfix boxes on Mandrake to replace Exchange boxes.

Funny thing is, not one client has had even a single complaint about their postfix mail servers.

Gladly, PDR60.

(only thing changed in the output is the "my" in my.dyndns.org).

Thanks in advance.

Ok cool. Couple of questions though. you do not have an entry for "mydomain"
nor is there one for mydestination. If you make it like this it should work.


postconf -n
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
default_privs = nobody
delay_warning_time = 4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain $mydomain
mydomain = domain.com
myhostname = host.domain.com
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.0.13/README_FILES
relayhost = 192.168.2.254
sample_directory = /usr/share/doc/postfix-2.0.13/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
unknown_local_recipient_reject_code = 450

You notice I dont use procmail. I would comment it ou and then get it going. After its running then try it. Give it a try and see if it woks. You are almost there. this is off of a clients server I just changed the domain.