postfix-user list features undocumented

[Mike's unattended mail]

How do subscribers turn off the email distribution?

How can post acknowledgements be turned on?

Majordomo is poorly documented, and doing a "info postfix-users"
command only gives:

   info postfix-users
  [Last updated on: Wed Apr 25 7:50:55 2007]
  TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

  TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

  Thank you for using Postfix

Re: postfix-user list features undocumented

[Reindl Harald]

Am 20.10.2012 14:28, schrieb Mike's unattended mail:
> How do subscribers turn off the email distribution?
> How can post acknowledgements be turned on?

Sender: owner-postfix-us...@postfix.org
Precedence: bulk
List-Post: 
List-Help: 
List-Unsubscribe: 
List-Subscribe: 

> Majordomo is poorly documented

see above, the available options are always part
of the mail-headers (on any mailing-list i know)






signature.asc
Description: OpenPGP digital signature

Re: The ultimate email server

[Mike's unattended mail]

On 2012-09-21, Mikkel Bang  wrote:
>
> What are these more intelligent, less crude techniques you talk about?

  * content analysis (high quality but computationally costly)
  * greylisting

crude and sloppy cost-cutting approaches:

  * dnsbl
  * reject_non_fqdn_helo_hostname

The crude and sloppy approaches are used by:

  1) corporations maximizing profits.  Their market consists of naive
 users who have no idea how poor the server quality is -- iow,
 there is virtually no market demand for quality; price is
 everything.  And apart from costs, it's also a means for large
 players to monopolize, and control small players in an
 anti-competitive fashion.

  2) individual hot-heads on the frill, hostily driven by spam with an
 evangelical mission to block every piece of spam with reckless
 disregard for availability (loss of ham), and ultimately neglect
 EFF principles on ethical mail handling.

If you are not in either of those groups, and you can afford a quality
server, then you have enough storage space to deliver every single
message without exception, both ham and spam.  Of course, you deliver
the ham and spam to sensible locations, so the user has effective and
meaningful separation, and transparency to be able to validate the
filters, and adjust, without risking loss of legitimate messages.

Any fool can block spam.  Skilled admins are the ones who create a
system that accepts every single legitimate message in a non-lossy
manner, and separate it.

It's all about the legitimate mail.  The whole reason to run a mail
server is for legitimate mail.  Spam causes damage to legitimate
traffic - but nothing damages legitimate traffic more than the
over-zealous (or simply naive) anti-spammer.  The collateral damage is
actually the single biggest threat to legit mail -- bigger than spam
traffic itself.

Re: The ultimate email server

[Reindl Harald]

Am 20.10.2012 15:14, schrieb Mike's unattended mail:
> crude and sloppy cost-cutting approaches:
> 
>   * dnsbl
>   * reject_non_fqdn_helo_hostname
> 
> The crude and sloppy approaches are used by:
> 
>   1) corporations maximizing profits.  Their market consists of naive
>  users who have no idea how poor the server quality is -- iow,
>  there is virtually no market demand for quality; price is
>  everything.  And apart from costs, it's also a means for large
>  players to monopolize, and control small players in an
>  anti-competitive fashion

if you run a mail-server and "reject_non_fqdn_helo_hostname"
on the target is a problem for you it is pretty clear who
of both sides has the poor server quality

sloppy in context of a mailserver is lack a proper PTR and HELO





signature.asc
Description: OpenPGP digital signature

Re: The ultimate email server

[Jeroen Geilman]

On 10/20/2012 03:14 PM, Mike's unattended mail wrote:

On 2012-09-21, Mikkel Bang  wrote:

What are these more intelligent, less crude techniques you talk about?

   * content analysis (high quality but computationally costly)
   * greylisting

crude and sloppy cost-cutting approaches:

   * dnsbl
   * reject_non_fqdn_helo_hostname


I am curious how you arrive at this blatantly provocative judgement.

DNSBLs are recommended  by just about everyone who is serious about 
email, and a proper EHLO is actually an RFC requirement.


This makes me wonder if it isn't you who represents some sort of 
ulterior agenda.



--
J.

Re: The ultimate email server

[Mike's unattended mail]

On 2012-10-20, Jeroen Geilman  wrote:
>
> DNSBLs are recommended by just about everyone who is serious about
> email,

There are a couple ways to use DNSBLs.  There are those who are
"serious" but either incompetent or on a cost-saving agenda, and then
there are those who are "serious", and have enough budget to use
DNSBLs competently.

The incompetent use of DNSBLs:

  This group uses DNSBLs as originally intended - to *block*
  connections.  This reckless approach (in effect) guarantees denial
  of service on the sole basis of IP address, neglecting more
  effective criteria.  Not only is the judgement as to whether the
  message is spam or ham cheapened, it violates EFF principles.

The competent use of DNSBLs:

  This group uses DNSBLs not to block, but rather to aggregate DNSBL
  tests with other more effective characteristics of the message.
  Instead of foolishly allocating all weight of the message treatment
  to one single factor, the finding is appropriately weighted with
  other factors.  And even if the message is judged to be spam through
  a more careful process, /it is still delivered/, and rightly so.

Keep in mind that the OP called for the "ultimate" mail server, not
the cheapest one.  To me this implies that quality *trumps* revenue
and cost-savings (as opposed to being one of many profit-driven
factors).

> and a proper EHLO is actually an RFC requirement.

You should read the requirement.  The RFC certainly does not insist
that senders buy a domain name.  The RFC allows for senders who do not
own a domain name to supply their literal address (aka IP address) for
the EHLO.  Such a message is RFC compliant, but blocked by those who
are uninformed about this and implement reject_non_fqdn_helo_hostname.
It is indeed a common misconception that the RFC requires a hostname
for the EHLO.

Re: The ultimate email server

[The Stovebolt Geek]

--On October 20, 2012 1:14:19 PM + Mike's unattended mail 
 wrote:



On 2012-09-21, Mikkel Bang  wrote:


What are these more intelligent, less crude techniques you talk about?


  * content analysis (high quality but computationally costly)
  * greylisting

crude and sloppy cost-cutting approaches:

  * dnsbl
  * reject_non_fqdn_helo_hostname

The crude and sloppy approaches are used by:



This post proves one thing.  Everyone is entitled to an opinion no matter 
how uninformed or ignorant it may be.


Paul Schmehl (g...@stovebolt.com)
The Stovebolt Geek
The Net's Oldest and Most Complete
Resource for Antique Chevy and GM Trucks
http://www.stovebolt.com

Re: postfix-user list features undocumented

[Mike's unattended mail]

On 2012-10-20, Reindl Harald  wrote:
> Am 20.10.2012 14:28, schrieb Mike's unattended mail:
>> How do subscribers turn off the email distribution?
>> How can post acknowledgements be turned on?
>
> Sender: owner-postfix-us...@postfix.org
> Precedence: bulk
> List-Post: 
> List-Help: 
> List-Unsubscribe: 
> List-Subscribe: 

That does not answer the question.  Of course, I already checked the
help page.

>> Majordomo is poorly documented
>
> see above, the available options are always part
> of the mail-headers (on any mailing-list i know)

I have been on hundreds of lists, and never known one to show all list
options in the header.  Check out a list running on mailman for
example (like procmail-users or gnucash-users).  The options span
several screens full, but only subscribe and unsubscribe are mentioned
in the headers.

Re: The ultimate email server

[The Stovebolt Geek]

--On October 20, 2012 5:27:09 PM + Mike's unattended mail 
 wrote:



On 2012-10-20, Jeroen Geilman  wrote:


DNSBLs are recommended by just about everyone who is serious about
email,


There are a couple ways to use DNSBLs.  There are those who are
"serious" but either incompetent or on a cost-saving agenda, and then
there are those who are "serious", and have enough budget to use
DNSBLs competently.

The incompetent use of DNSBLs:

  This group uses DNSBLs as originally intended - to *block*
  connections.  This reckless approach (in effect) guarantees denial
  of service on the sole basis of IP address, neglecting more
  effective criteria.  Not only is the judgement as to whether the
  message is spam or ham cheapened, it violates EFF principles.

The competent use of DNSBLs:

  This group uses DNSBLs not to block, but rather to aggregate DNSBL
  tests with other more effective characteristics of the message.
  Instead of foolishly allocating all weight of the message treatment
  to one single factor, the finding is appropriately weighted with
  other factors.  And even if the message is judged to be spam through
  a more careful process, /it is still delivered/, and rightly so.

Keep in mind that the OP called for the "ultimate" mail server, not
the cheapest one.  To me this implies that quality *trumps* revenue
and cost-savings (as opposed to being one of many profit-driven
factors).


and a proper EHLO is actually an RFC requirement.


You should read the requirement.  The RFC certainly does not insist
that senders buy a domain name.  The RFC allows for senders who do not
own a domain name to supply their literal address (aka IP address) for
the EHLO.  Such a message is RFC compliant, but blocked by those who
are uninformed about this and implement reject_non_fqdn_helo_hostname.
It is indeed a common misconception that the RFC requires a hostname
for the EHLO.



So now we get to the crux of the problem.  He runs his mail server without 
a hostname and has been placed on DNSBLs at times.  This has caused his 
mail to be rejected, and he's irritated about that.


Here's another view.  I run a mail server that has a proper hostname, 
reverses correctly and use spf.  We've never had our mail rejected and 
never been on a DNSBL.


But then I've never been one to rigidly demand that everyone else comply 
with my concept of what is "right".


You might consider doing that.

Paul Schmehl (g...@stovebolt.com)
The Stovebolt Geek
The Net's Oldest and Most Complete
Resource for Antique Chevy and GM Trucks
http://www.stovebolt.com

Re: postfix-user list features undocumented

[Reindl Harald]

Am 20.10.2012 19:43, schrieb Mike's unattended mail:
> On 2012-10-20, Reindl Harald  wrote:
>> Am 20.10.2012 14:28, schrieb Mike's unattended mail:
>>> How do subscribers turn off the email distribution?
>>> How can post acknowledgements be turned on?
>>
>> Sender: owner-postfix-us...@postfix.org
>> Precedence: bulk
>> List-Post: 
>> List-Help: 
>> List-Unsubscribe: 
>> List-Subscribe: 
> 
> That does not answer the question.  Of course, I already checked the
> help page.

what do you need mor than subscribe / unsubscribe?

however after your suggestions in the thread
"The ultimate email server" you have really much
bigger troubles



signature.asc
Description: OpenPGP digital signature

Re: The ultimate email server

[Robert Schetterer]

Am 20.10.2012 18:01, schrieb Jeroen Geilman:
> On 10/20/2012 03:14 PM, Mike's unattended mail wrote:
>> On 2012-09-21, Mikkel Bang  wrote:
>>> What are these more intelligent, less crude techniques you talk about?
>>* content analysis (high quality but computationally costly)
>>* greylisting
>>
>> crude and sloppy cost-cutting approaches:
>>
>>* dnsbl
>>* reject_non_fqdn_helo_hostname
> 
> I am curious how you arrive at this blatantly provocative judgement.
> 
> DNSBLs are recommended  by just about everyone who is serious about
> email, and a proper EHLO is actually an RFC requirement.
> 
> This makes me wonder if it isn't you who represents some sort of
> ulterior agenda.
> 
> 

sometimes you have to face real world, so whitelisting has to be done
with some servers

perhaps do it like this

smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
...
check_client_access hash:/etc/postfix/whitelist_client_helo_hostname_access,
reject_invalid_hostname,
reject_non_fqdn_hostname,
check_helo_access hash:/etc/postfix/helo_access,
...
reject_unauth_pipelining

with i.e

/etc/postfix/helo_access

localhost   REJECT i am  localhost myself



and yes youre right
rbls are a strong tool, but have to be choosen in a critical mind about
their special functions and relate your setup needs

combined with some other antispam stuff and selective setup
rbls are working fine ( which means less false postives )
so you might work with smtpd_restriction_classes

anyway checking logs and monitoring is daily postmaster work
you never will goal the ultimate mailserver setup ( so the subject is is
wrong anyway), in special
when you do mailhosting for other people, so your setup has to face
always the real needs of the day to provide best service you can,
so you have to jugde daily new what fits best to your needs these spamdays

searching postfix archives and www sites should be good enough finding
a good starting setup for postfix, if facing any problems
then ,the list is right place to ask


-- 
Best Regards
MfG Robert Schetterer

[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich

Re: Alert of unusually large queue

[Reindl Harald]

Am 16.10.2012 15:20, schrieb James Day:
> I use the following to do just that. I'm sure there is a better way but I 
> fudged this together myself
> 
> Script 1:
> 
> #!/bin/bash
> 
> /usr/bin/mailq | /usr/bin/tail -n1 | /usr/bin/gawk '{print $5}' > 
> /etc/postfix/mailq_count
> 
> Script 2:
> 
> #!/bin/bash
> 
> mailq_count="/bin/cat /etc/postfix/mailq_count"
> 
> if [ `$mailq_count` -gt 50 ]; then echo "Mail count on Server is" 
> `$mailq_count`|/usr/sbin/sendmail -f r...@example.com repo...@example.com ; fi
> 
> 
> These run as cron jobs every few minutes.

thank you for that

i optimized this to one script without temp-file

mailq_count=`expr $mailq_count + 0`
this makes sure that we have a number if queue is empty
otherwise: /usr/local/bin/watch-queue.sh: line 4: [: -gt: unary operator 
expected
_

#!/bin/bash
mailq_count=`/usr/bin/mailq | /usr/bin/tail -n1 | /usr/bin/gawk '{print $5}'`
mailq_count=`expr $mailq_count + 0`
if [ $mailq_count -gt 50 ]; then
 echo "Mail count on Server is $mailq_count"
fi



signature.asc
Description: OpenPGP digital signature

Re: postfix-user list features undocumented

[Larry Stone]

On Oct 20, 2012, at 12:43 PM, Mike's unattended mail 
 wrote:

> On 2012-10-20, Reindl Harald  wrote:
>> Am 20.10.2012 14:28, schrieb Mike's unattended mail:
>>> How do subscribers turn off the email distribution?
>>> How can post acknowledgements be turned on?
>> 
>> Sender: owner-postfix-us...@postfix.org
>> Precedence: bulk
>> List-Post: 
>> List-Help: 
>> List-Unsubscribe: 
>> List-Subscribe: 
> 
> That does not answer the question.  Of course, I already checked the
> help page.

It answers it the way I am interpreting the first question which "how do you 
unsubscribe?". Perhaps the question you're asking is not clear to us. The 
language you are using is a bit awkward. What do you mean by "turn off the 
email distributions" if it doesn't mean "unsubscribe".

As for the second question, receiving your own post back does an adequate job 
of acknowledging the post. Unless, of course, you mean something different when 
you say "post acknowledgements".

-- 
Larry Stone
lston...@stonejongleux.com
http://www.stonejongleux.com/

Re: Alert of unusually large queue

[Jan P. Kessler]

Hey guys,

> if [ `$mailq_count` -gt 50 ]; then echo "Mail count on Server is" 
> `$mailq_count`|/usr/sbin/sendmail -f r...@example.com repo...@example.com ; fi

I'm not sure, if sending an e-mail about a "full mailqueue"-condition is
the best way to go ;-)

cheers, Jan

Re: postfix-user list features undocumented

[Ralf Hildebrandt]

* Larry Stone :

> It answers it the way I am interpreting the first question which "how
> do you unsu*sc*ibe?". Perhaps the question you're asking is not clear
> to us. The language you are using is a bit awkward. What do you mean by
> "turn off the email distributions" if it doesn't mean "unsu*sc*ibe".

With mailman one can deactivate receiving mails but still be a member
(during vacation for example)
 
> As for the second question, receiving your own post back does an
> adequate job of acknowledging the post. Unless, of course, you mean
> something different when you say "post acknowledgements".

Also something that Mailman does: If a post is held and later released
by an admin, one can receive a "post acknowledgements" (which only
makes sense when you're NOT a member or you disabled receiving mails.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Alert of unusually large queue

[Reindl Harald]

Am 20.10.2012 22:08, schrieb Jan P. Kessler:
> Hey guys,
> 
>> if [ `$mailq_count` -gt 50 ]; then echo "Mail count on Server is" 
>> `$mailq_count`|/usr/sbin/sendmail -f r...@example.com repo...@example.com ; 
>> fi
> 
> I'm not sure, if sending an e-mail about a "full mailqueue"-condition is
> the best way to go ;-)

depends

if you have no bulk-mail on your server it will tak enot too long
to find a good value to adjust the "50" and as example if i have
500 queued messages i like to look if there is soemthing going
wrong

the only optimizing for me would be to send another notify
if the count goes down and prevent sending multiple notfies
after reaching the configured limit



signature.asc
Description: OpenPGP digital signature

Re: postfix-user list features undocumented

[Reindl Harald]

Am 20.10.2012 22:38, schrieb Ralf Hildebrandt:
> * Larry Stone :
> 
>> It answers it the way I am interpreting the first question which "how
>> do you unsu*sc*ibe?". Perhaps the question you're asking is not clear
>> to us. The language you are using is a bit awkward. What do you mean by
>> "turn off the email distributions" if it doesn't mean "unsu*sc*ibe".
> 
> With mailman one can deactivate receiving mails but still be a member
> (during vacation for example)

a proper mailserver will not respond to messages wtih a
"Precedence: bulk" header and not respond more than once
each day to the same sender



signature.asc
Description: OpenPGP digital signature

Re: Alert of unusually large queue

[CSS]

On Oct 20, 2012, at 4:08 PM, Jan P. Kessler wrote:

> Hey guys,
> 
>> if [ `$mailq_count` -gt 50 ]; then echo "Mail count on Server is" 
>> `$mailq_count`|/usr/sbin/sendmail -f r...@example.com repo...@example.com ; 
>> fi
> 
> I'm not sure, if sending an e-mail about a "full mailqueue"-condition is
> the best way to go ;-)

Any of these checks could be handled by Nagios or anything else that can easily 
execute a remote command.  Or tie it into your snmp daemon…

But yeah, a problem with a giant queue that piles up between cron'd intervals 
could certainly lead to some missed alerts. :)

Charles

> cheers, Jan
> 

chroot recommendations/BCP?

[CSS]

Hello,

I was just digging through the documentation on running various postfix 
processes chrooted.  I found the recommendation that at least the 
network-facing daemons be chrooted, but it appears that almost everything in 
master.cf can be.  What's the current BCP for what to chroot and what not to 
chroot?

This box in particular (and probably another few boxes) will not be doing local 
delivery - they are either acting as relays for authenticated customers or 
mxers fronting an old qmail/vpopmail install.  I assume things are slightly 
more complex if I need to deliver mail locally.  I did not detect any issues 
when basically setting chroot to "y" on everything, but that seemed too 
simple...

Also, I could not find a clear list of what postfix requires in the chroot 
environment.  I looked at the "Freebsd3" script, and populated etc/ inside the 
chroot as indicated and I added a syslog socket.  Do I need any other devices 
like /dev/null, /dev/[u]random, etc?  It would be great to have the hard 
requirements in the online docs.

Thanks,

Charles

Re: chroot recommendations/BCP?

[Wietse Venema]

CSS:
> Hello,
> 
> I was just digging through the documentation on running various
> postfix processes chrooted.  I found the recommendation that at
> least the network-facing daemons be chrooted, but it appears that
> almost everything in master.cf can be.  What's the current BCP for
> what to chroot and what not to chroot?

If a daemon can be chrooted, then the manpage will say so. That
does not mean that chroot is a good idea for every Postfix
configuration.  If you are unsure if chroot is useful for you, then
it probably isn't, and you can save yourself the pain.

Wietse

Re: Alert of unusually large queue

[Robert Schetterer]

Am 20.10.2012 22:08, schrieb Jan P. Kessler:
> Hey guys,
> 
>> if [ `$mailq_count` -gt 50 ]; then echo "Mail count on Server is" 
>> `$mailq_count`|/usr/sbin/sendmail -f r...@example.com repo...@example.com ; 
>> fi
> 
> I'm not sure, if sending an e-mail about a "full mailqueue"-condition is
> the best way to go ;-)
> 
> cheers, Jan
> 

perhaps  use nagios, xymon etc monitor prog

so i.e the monitor client actions some mailq watch script
which results go to the monitor server, which alerts you via mail and/or
sms

-- 
Best Regards
MfG Robert Schetterer

[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich