mailbox_command

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

mailbox_command

Danny-125
Hi guys,

I am running Debian 5.4 with postfix 2.5.5-1.1, fetchmail 6.3.9rc2-4 and
procmail 3.22-16.

Now, before I upgraded to Debian 5.4 I had Debian 4.0 running the same postfix,
fetchmail & procmail setup(with different versions obviously).

Fetchmail got the mail, gave it to procmail via the ("mda formail -s procmail")
flag in my /etc/fetchmailrc file.

Everything was running just nicely.

So now I upgraded to Debian 5.4 and it seems like fetchmail is no longer calling
procmail. Fetchmail just dumps everything into the /var/spool/mail/fetchmail
file. It looks like it is bypassing the "mda" flag.

My .procmailrc file is fine I think.

So someone I know said that I should delete the following command in postfix's
main.cf file ....

mailbox_command = /usr/bin/procmail -a "$EXTENSION"

... but this does not change anything. Am I missing something here?

My /etc/fetchmail file is like this:
#####################################
set syslog
set postmaster "root"
set no bouncemail
set logfile "/var/log/fetchmail.log"
set spambounce

poll ###.###.###.###
  proto pop3
  user "username"
  pass "password"
  fetchall
  expunge 50
  mda "formail -s procmail"
####################################

The top of my /root/.procmailrc file looks like this:
###################################
SHELL=/bin/sh
PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin
MAILDIR=~/Mail
LOGFILE=/var/log/procmail.log
LOGABSTRACT="all"
VERBOSE="on"
DEFAULT=~/Mail/inbox
#DEFAULT=/var/mail/fetchmail
PMDIR=$HOME=~/.procmail
#INCLUDERC=$PMDIR/spam.rc

I don't want to rewrite headers through formail or procmail. This is a home
setup, and fetchmail must just go get the mail and pass it to procmail.

Thank you in advance

Danny
Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

/dev/rob0
On Thu, Apr 22, 2010 at 05:20:37PM +0200, Danny wrote:
> I am running Debian 5.4 with postfix 2.5.5-1.1, fetchmail
> 6.3.9rc2-4 and procmail 3.22-16.
>
> Now, before I upgraded to Debian 5.4 I had Debian 4.0 running the
> same postfix, fetchmail & procmail setup(with different versions
> obviously).
>
> Fetchmail got the mail, gave it to procmail via the ("mda formail
> -s procmail") flag in my /etc/fetchmailrc file.

Nothing in any of that indicates that you really are doing anything
with Postfix. You use fetchmail(1) to retrieve (POP3 or IMAP) from a
remote server, then pass to the procmail(1) delivery agent.

> Everything was running just nicely.
>
> So now I upgraded to Debian 5.4 and it seems like fetchmail is no
> longer calling procmail. Fetchmail just dumps everything into the
> /var/spool/mail/fetchmail file. It looks like it is bypassing the
> "mda" flag.

Then I guess you might have a Debian packaging bug. You should
probably file a Debian bug against fetchmail. (It could be an
upstream bug too, but the Debian fetchmail maintainer should know.)

> My .procmailrc file is fine I think.
>
> So someone I know said that I should delete the following command
> in postfix's main.cf file ....
>
> mailbox_command = /usr/bin/procmail -a "$EXTENSION"
>
> ... but this does not change anything. Am I missing something here?

The right mailing list. :) Also, apparently not understanding that
Postfix plays no role in the mail handling you described. If there
really IS a Postfix issue, see here before posting again:

    http://www.postfix.org/DEBUG_README.html#mail

> My /etc/fetchmail file is like this:
> #####################################
> set syslog
> set postmaster "root"
> set no bouncemail
> set logfile "/var/log/fetchmail.log"
> set spambounce
>
> poll ###.###.###.###
>   proto pop3
>   user "username"
>   pass "password"
>   fetchall
>   expunge 50
>   mda "formail -s procmail"
> ####################################
>
> The top of my /root/.procmailrc file looks like this:

This whole thing appears to be off topic, but one thing I will
mention: it's wrong and potentially dangerous to handle user tasks
like mail as root. This looks like it should all be done from a
non-root user account.

> ###################################
> SHELL=/bin/sh
> PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin
> MAILDIR=~/Mail
> LOGFILE=/var/log/procmail.log
> LOGABSTRACT="all"
> VERBOSE="on"
> DEFAULT=~/Mail/inbox
> #DEFAULT=/var/mail/fetchmail
> PMDIR=$HOME=~/.procmail
> #INCLUDERC=$PMDIR/spam.rc
>
> I don't want to rewrite headers through formail or procmail. This
> is a home setup, and fetchmail must just go get the mail and pass
> it to procmail.

--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

mailbox_command

Danny-125
HI ,

I am well aware that postfix plays no part in the process I describe below, I
merely wanted to know if the mailbox_command would play a part in it. That is
why I gave you a little background (like normal) before I asked about the
mailbox_command. Do not asume that all first-time posters are idiots, in fact,
do not assume that anyone is an idiot.

The mailbox_command is a postfix command, that is why I posted it here. It is
part of the process of finding the fault. I just
wanted an opinion not a lecture. Not all of us sit around computers everyday,
some of us have a different dayjob than many on this list, just help us, don't
scold us.

But I apologise for posting such a simple query on the all mighty postfix
mailing-list. Maybe you should have a list called :
[hidden email].

Don't you think that "it must be a bug" is a bit superflous? No it is not, it is
the easiest way to send a first time poster on his way. It is obviuos that you
have better things to discuss on this mailing than answer simple questions. Why don't
you make this list an exclusive club for the initiated and seasoned postfix user
only?

Thank You

Danny

On Apr 22 10, /dev/rob0 :

> To: [hidden email]
> Date: Thu, 22 Apr 2010 23:13:42 -0500
> From: /dev/rob0 <[hidden email]>
> Subject: Re: mailbox_command
> User-Agent: Mutt/1.5.19 (2009-01-05)
>
> On Thu, Apr 22, 2010 at 05:20:37PM +0200, Danny wrote:
> > I am running Debian 5.4 with postfix 2.5.5-1.1, fetchmail
> > 6.3.9rc2-4 and procmail 3.22-16.
> >
> > Now, before I upgraded to Debian 5.4 I had Debian 4.0 running the
> > same postfix, fetchmail & procmail setup(with different versions
> > obviously).
> >
> > Fetchmail got the mail, gave it to procmail via the ("mda formail
> > -s procmail") flag in my /etc/fetchmailrc file.
>
> Nothing in any of that indicates that you really are doing anything
> with Postfix. You use fetchmail(1) to retrieve (POP3 or IMAP) from a
> remote server, then pass to the procmail(1) delivery agent.
>
> > Everything was running just nicely.
> >
> > So now I upgraded to Debian 5.4 and it seems like fetchmail is no
> > longer calling procmail. Fetchmail just dumps everything into the
> > /var/spool/mail/fetchmail file. It looks like it is bypassing the
> > "mda" flag.
>
> Then I guess you might have a Debian packaging bug. You should
> probably file a Debian bug against fetchmail. (It could be an
> upstream bug too, but the Debian fetchmail maintainer should know.)
>
> > My .procmailrc file is fine I think.
> >
> > So someone I know said that I should delete the following command
> > in postfix's main.cf file ....
> >
> > mailbox_command = /usr/bin/procmail -a "$EXTENSION"
> >
> > ... but this does not change anything. Am I missing something here?
>
> The right mailing list. :) Also, apparently not understanding that
> Postfix plays no role in the mail handling you described. If there
> really IS a Postfix issue, see here before posting again:
>
>     http://www.postfix.org/DEBUG_README.html#mail
>
> > My /etc/fetchmail file is like this:
> > #####################################
> > set syslog
> > set postmaster "root"
> > set no bouncemail
> > set logfile "/var/log/fetchmail.log"
> > set spambounce
> >
> > poll ###.###.###.###
> >   proto pop3
> >   user "username"
> >   pass "password"
> >   fetchall
> >   expunge 50
> >   mda "formail -s procmail"
> > ####################################
> >
> > The top of my /root/.procmailrc file looks like this:
>
> This whole thing appears to be off topic, but one thing I will
> mention: it's wrong and potentially dangerous to handle user tasks
> like mail as root. This looks like it should all be done from a
> non-root user account.
>
> > ###################################
> > SHELL=/bin/sh
> > PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin
> > MAILDIR=~/Mail
> > LOGFILE=/var/log/procmail.log
> > LOGABSTRACT="all"
> > VERBOSE="on"
> > DEFAULT=~/Mail/inbox
> > #DEFAULT=/var/mail/fetchmail
> > PMDIR=$HOME=~/.procmail
> > #INCLUDERC=$PMDIR/spam.rc
> >
> > I don't want to rewrite headers through formail or procmail. This
> > is a home setup, and fetchmail must just go get the mail and pass
> > it to procmail.
>
> --
>     Offlist mail to this address is discarded unless
>     "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

Wietse Venema
Danny:
> HI ,
>
> I am well aware that postfix plays no part in the process I describe below, I
> merely wanted to know if the mailbox_command would play a part in it. That is
> why I gave you a little background (like normal) before I asked about the
> mailbox_command. Do not asume that all first-time posters are idiots, in fact,
> do not assume that anyone is an idiot.

You need to show logfile evidence that Postfix is actually part of
your problem. I hope that is not too much to be asked.

        Wietse
Reply | Threaded
Open this post in threaded view
|

mailbox_command

Danny-125
Hi Wietse,

No, it is not too much to ask. I and MANY other people have been supporting open
source for a VERY VERY long time. We, in our own little way, have spread the
open-source gospel to just as many people. We contribute where we can, maybe not
in an "important" way like designing a mailserver, or a webserver. We do not
hack kernels, we do not slap a driver together in 10 minutes for an unsupported
piece of hardware. We are not on the OpenSSH or OpenSSL coding team. No, we are
just ordinary people who fight for a just cause. We inform people that there are
other alternatives, better alternatives. We tell people and businesses about
OpenBSD, postfix, apache, samba, debian etc. We do this when we do our normal
day to day jobs that are not related to computers. We do this when we get home
on mailing lsts like this. We do this after we washed the grease and oil from
our hands and faces. We are the ones in the dungeons feeding the fires and axeing
the logs.

And then you come home one night after upgrading a system and experience a
problem. You post it to one of the relevant mailiing lists expecting a decent
well formed and thought-out answer and you get some wise-crack who gives you the
"it's a bug" answer.

I am an aircraft engineer. Everyday of my life I work from 6 in the morning
till 3 in the afternoon. I am expected to know the ins and outs of a Boeing
747-400 when in comes in with an electrical problem, I am expected to know a
Boeing 737-800 when the engines don't want to start, it is expected of me to rig
the flight controls on an Airbus A319 and many others. When an Airbus A340-600
pilot asks me why his Navigation control panel doesn't operate, I don't tell
him that it is a bug, NO ... If I don't know the answer I will consult the
aircraft manuals and FIND the possible causes of this, and then I will tell this
Pilot the conclusions I have come to and the different avenues I will explore in
correcting this fault. I DON'T TELL HIM IT IS A FREAKIN BUG ....

The problem with mailing lists like these, including mailing lists like OpenBSD
et.al is that those of us that are not "known" in the open-source circles and
those of us that do not contribute to some obscure "matrix hashing algorithm"
and those of us who do not hog mailing lists like these are undermined and
shrugged off as idiots. We ask the "wrong" monotonous over-explained questions.
We get answers like "Read the f**** manual" or "it's been answered to death" or
"why don't you go read the (underexplained, not so obvious) examples in the
manual" or "IT's a BUG".

All I wanted to know from this mailing list is if the "mailbox_command" will
influence the way fetchmail operates, THAT IS ALL. I know what fetchmail does, I
know what procmail does and I have some idea of the purpose of an MTA like
postfix. The reason I posted here is because POSTFIX, not exim, not sendmail but
POSTFIX is involved. POSTFIX calls fetchamail in the postfix main.cf
via the mailbox_command. SO DO NOT TELL ME THAT I AM ON THE WRONG FREAKIN
MAILING LIST.

Thank You

Danny
> You need to show logfile evidence that Postfix is actually part of
> your problem. I hope that is not too much to be asked.
>
> Wietse
Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

Victor Duchovni
On Fri, Apr 23, 2010 at 07:59:17PM +0200, Danny wrote:

> So do not tell me that I am on the wrong [...] mailing list.

Hopefully, we can down-case this thread and avoid "them fighting words".

We don't know you. Most questions asked on this list are asked by people
who "do not know how to ask". Specifically, the questions omit crucial
configuration details, summarize re-interpret observations instead
of providing complete log data, and focus on the "obstacle" (what's
failing) rather than the "goal" (what is the ultimate objective).

The vast majority of problems are solved by:

    - Disengaging locked horns with "obstacle" and re-examining the problem.
      Perhaps the right approach side-steps the obstacle entirely.

    - Providing a clear description of the goals, accurate configuration
      information and unsummarized logging. Then explain the obstacle
      faced, what you expected to happen, and relate your observations of
      what happened to the reported logs.

    - Not economizing on the logs posted, post everything related to
      the problem delivery.

    - Keeping your cool and taking in-stride requests for more
      information and/or skepticism about alleged behaviour not
      backed up with sound logs and configuration details.

The people helping you are also busy, and also have pressures and time
constraints. Since they are volunteering to help you, the burden of doing
your home-work so that we can do so in a time-effective way is on you.

If you can't main composure, please vent somewhere else: tell your
spouse or bartender about those mean SOBs on the email support list,
will probably be more sympathetic.

--
        Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment.  If you are interested, please drop me a note.
Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

d.hill
In reply to this post by Danny-125
Quoting Danny <[hidden email]>:

> POSTFIX calls fetchamail in the postfix main.cf
> via the mailbox_command. SO DO NOT TELL ME THAT I AM ON THE WRONG FREAKIN
> MAILING LIST.

Did Wietse tell you you were on the wrong mailing list? He simply  
asked for logs showing Postfix was actually part of your problem.

>> You need to show logfile evidence that Postfix is actually part of
>> your problem. I hope that is not too much to be asked.
>>
>> Wietse
>



Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

Wietse Venema
In reply to this post by Danny-125
Danny:
> Hi Wietse,
>
> No, it is not too much to ask. I and MANY other people have been
> supporting open source for a VERY VERY long time. We, in our own

Then, your next step is to produce logfile evidence that confirms
that Postfix is actually part of the problem.

There is no need to reply with a sermon. Just come up with the logs.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

/dev/rob0
In reply to this post by Danny-125
Reply-To: /dev/null :: EOT for me.

On Fri, Apr 23, 2010 at 06:16:31PM +0200, Danny wrote the first of a
series of rants, none worthy of quoting here.

I suggest you go back and reread my helpful reply. It contained some
useful advice and simple instructions for how to get real help with
the problem you originally posted about.

To the others on the list, I am sorry. I have no idea how I trigger
these responses. I really thought it was a helpful reply.


PS: Danny does not inspire much confidence in the aviation industry.
A bit of unsolicited personal advice to him: tone down the bragging.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

mailbox_command

Danny-125
And you do not inspire much confidence in the IT industry if you think your
answer was helpfull. My personal advice to you ... get away from your screen
every now and then ... there is a real life if you just open your front door.

>On Apr 23 10, /dev/rob0 :
>
> PS: Danny does not inspire much confidence in the aviation industry.
> A bit of unsolicited personal advice to him: tone down the bragging.
> --
Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

Wietse Venema
Danny:
> And you do not inspire much confidence in the IT industry if you think your
> answer was helpfull. My personal advice to you ... get away from your screen
> every now and then ... there is a real life if you just open your front door.

Danny, when are you going to provide the logfile evidence that is
needed to solve the problem? I will not ask again.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

Ansgar Wiechers
In reply to this post by Danny-125
On 2010-04-24 Danny wrote:
> And you do not inspire much confidence in the IT industry if you think
> your answer was helpfull. My personal advice to you ... get away from
> your screen every now and then ... there is a real life if you just
> open your front door.
>
>>On Apr 23 10, /dev/rob0 :
>>
>> PS: Danny does not inspire much confidence in the aviation industry.
>> A bit of unsolicited personal advice to him: tone down the bragging.

http://slash7.com/2006/12/22/vampires/

Reply-To set to myself, as this is getting off-topic.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky
Reply | Threaded
Open this post in threaded view
|

Re: mailbox_command

Kris Deugau
In reply to this post by Danny-125
Danny wrote:
> HI ,
>
> I am well aware that postfix plays no part in the process I describe below,

... but then you say:

> I
> merely wanted to know if the mailbox_command would play a part in it.

?

mailbox_command is a Postfix *configuration directive*, not a binary,
script, or other Postfix-related file.  So if you're not passing your
mail through Postfix from fetchmail, Postfix configuration has no effect
on what fetchmail does with your mail.

> Don't you think that "it must be a bug" is a bit superflous? No it is not, it is
> the easiest way to send a first time poster on his way. It is obviuos that you
> have better things to discuss on this mailing than answer simple questions. Why don't
> you make this list an exclusive club for the initiated and seasoned postfix user
> only?

You noted in your original post:

    It looks like it is bypassing the  "mda" flag.

And /dev/rob0 replied to that paragraph with "you might have a *Debian
packaging bug*" (emphasis mine).

A bug, as in, "unexpected behaviour due to an error in the program".

That misbehaviour might be due to some screwup on the part of the Debian
package maintainer, or the upstream fetchmail author - filing a Debian
bug is the usual way to find out.  (After you've crosschecked the
documentation for the current version in case some knucklehead thought
it would be fun to change certain default behaviours, or how some
long-standing options are processed, without trying to put up a great
big neon sign warning you about those changes.)

-kgd