Prev: giving more headers
Next: Postfix sending NDR instead of rejecting in SMTP session
From: Danny on 23 Apr 2010 13:59
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

From: d.hill on 23 Apr 2010 12:31
Quoting Danny <dannydebont(a)gmail.com>:

> 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
>

From: Victor Duchovni on 23 Apr 2010 12:27
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.

From: Wietse Venema on 23 Apr 2010 12:42
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

From: /dev/rob0 on 23 Apr 2010 00:13
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

 |  Next  |  Last
Pages: 1 2
Prev: giving more headers
Next: Postfix sending NDR instead of rejecting in SMTP session