Re: Graphical stats by domain

[Antoine Nguyen]

Muzaffer Tolga Özses  wrote:
>Good morning everyone :)
>
>Do you guys know of a tool that will act like pflogsumm, only based on 
>domain and graphical?
>
>Regards,
>

Hi,

take a look at modoboa (http://modoboa.org/). It supports per-domain graphical 
stats using RRDtool.

Antoine

Re: Graphical stats by domain

[Muzaffer Tolga Özses]

On 04/04/2013 10:30 AM, Antoine Nguyen wrote:

Muzaffer Tolga Özses  wrote:

Good morning everyone :)

Do you guys know of a tool that will act like pflogsumm, only based on
domain and graphical?

Regards,


Hi,

take a look at modoboa (http://modoboa.org/). It supports per-domain graphical 
stats using RRDtool.

Antoine
Thanks, but I'm not looking to replace my reader. What I want is 
something more simple.


M.

Re: Verify cache dump

[Nikolaos Milas]

On 23/1/2013 3:43 μμ, Nikolaos Milas wrote:

Interestingly, at first I tried it but it didn't seem to produce any 
output at all (I had to break with Ctrl-C):


# postmap -s /var/lib/postfix/verify_cache
^C
# postmap -s btree:/var/lib/postfix/verify_cache
^C
# postmap -q u...@example.com /var/lib/postfix/verify_cache
^C
# postmap -q u...@example.com btree:/var/lib/postfix/verify_cache
^C

Finally it worked as follows:

# postmap -s btree:/var/lib/postfix/verify_cache
# postmap -q u...@example.com btree:/var/lib/postfix/verify_cache 


I continue to have this problem (no output from verify_cache querying).

For example, it occurs on two servers with 2.9.4 (CentOS 6.3 x86_64).

How can I troubleshoot it to see why it happens?

If I run verbose:

# postmap -vs btree:/var/lib/postfix/verify_cache
postmap: name_mask: ipv4
postmap: name_mask: ipv6
postmap: inet_addr_local: configured 2 IPv4 addresses
postmap: inet_addr_local: configured 3 IPv6 addresses
postmap: Compiled against Berkeley DB: 4.7.25?
postmap: Run-time linked against Berkeley DB: 4.7.25?
^C

(It hungs, so I Ctrl-C.)

Thanks,
Nick

Re: Graphical stats by domain

[Marko Weber | ZBF]

Am 2013-04-04 10:12, schrieb Muzaffer Tolga Özses:

On 04/04/2013 10:30 AM, Antoine Nguyen wrote:

Muzaffer Tolga Özses  wrote:

Good morning everyone :)

Do you guys know of a tool that will act like pflogsumm, only based 
on

domain and graphical?

Regards,


Hi,

take a look at modoboa (http://modoboa.org/). It supports per-domain 
graphical stats using RRDtool.


Antoine

Thanks, but I'm not looking to replace my reader. What I want is
something more simple.

M.


hmm, try out "mailgraph" http://mailgraph.schweikert.ch/

or "Munin" it can also monitor mailing. http://munin-monitoring.org/

and maybe you find in the plugin collection a plugin that do extended 
jobs of what you need.



best regards
m4rko from sunny hamburg (germany)

Re: Verify cache dump

[Wietse Venema]

Nikolaos Milas:
> On 23/1/2013 3:43 ??, Nikolaos Milas wrote:
> 
> > Interestingly, at first I tried it but it didn't seem to produce any 
> > output at all (I had to break with Ctrl-C):
> >
> > # postmap -s /var/lib/postfix/verify_cache
> > ^C
> > # postmap -s btree:/var/lib/postfix/verify_cache
> > ^C
> > # postmap -q u...@example.com /var/lib/postfix/verify_cache
> > ^C
> > # postmap -q u...@example.com btree:/var/lib/postfix/verify_cache
> > ^C

I have mentioned before that the verify(8) daemon locks the Berkeley
DB file exclusively. Concurrent read/write access is not safe with
these files. The exclusive lock guarantees that verify(8) will not
crash or do silly things when some other Postfix program changes
the database.  The lock also ensures that other Postfix programs
will not crash or do silly things when verify(8) changes the database.

You could do this:

# cp /var/lib/postfix/verify_cache.db tempfile.db
# postmap -s btree:tempfile.db

Cross your fingers, and if it breaks, repeat the two commands.

The new LMDB database type is safe for concurrent read/write access;
however this currently has an open problem when creating a very
large database file from scratch (as with the "postmap" command).
That is not an issue with verify(8) which makes only incremental
updates.

Of course there is no guarantee of what you will get when you dump
a large database while it is being modified, even when the database
file is safe for concurrent read/write access. But at least the
programs will not crash or do silly things.

Wietse

Re: Verify cache dump

[Nikolaos Milas]

On 4/4/2013 3:38 μμ, Wietse Venema wrote:


 # cp /var/lib/postfix/verify_cache.db tempfile.db
 # postmap -s btree:tempfile.db


Thanks Wietse, it works fine this way:

   # postmap -s btree:verify_cache_copy

By the way, is there a way/command to lengthen the validity of all 
current entries in the verify cache?


As currently set, our gateway mail server(s) queries the final 
destination (internal) server to verify recipients using:


   relay_recipient_maps = 

In case of planned downtime of internal (final destination) mail server, 
I would like to avoid expiration of the gateway server's verify cache 
during the downtime.


Thanks again,
Nick

Re: Verify cache dump

[Wietse Venema]

Nikolaos Milas:
> On 4/4/2013 3:38 ??, Wietse Venema wrote:
> 
> >  # cp /var/lib/postfix/verify_cache.db tempfile.db
> >  # postmap -s btree:tempfile.db
> 
> Thanks Wietse, it works fine this way:
> 
> # postmap -s btree:verify_cache_copy
> 
> By the way, is there a way/command to lengthen the validity of all 
> current entries in the verify cache?

Configure a larger address_verify_positive_expire_time?
The default is 31 days.

Note that Postfix does not wait until cached information expires.
By default it refreshes cached records after 7 days (the refresh
happens after the user receives email).

Therefore. cached information about active accounts will be valid
for 24..31 days.

> As currently set, our gateway mail server(s) queries the final 
> destination (internal) server to verify recipients using:
> 
> relay_recipient_maps = 
> 
> In case of planned downtime of internal (final destination) mail server, 
> I would like to avoid expiration of the gateway server's verify cache 
> during the downtime.

How long is your expected downtime? Even it someone receives only
one email per week, they should expire in 24 days.

Wietse

Re: Multiple recipient_delimiter address extensions?

[Kris Deugau]

grarpamp wrote:
> I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
> meta issue. Other users migration or dual uses aside, with that
> one I wanted to but did not have benefit to research whether
> + or - had better merits. Such as which is in more common use now,
> which is trending to be more prevalent in the long term. And why?
> Honestly, best I could come up with was the large - legacy from
> decade old qmail-like installations, and not requiring the shift key
> seemed to win, heh :) I'm sure there are more sound thoughts
> on the matter in a paper somewhere.

- has the fairly significant advantage of being allowed on more sites
that try to validate "well-formed" email addresses - often in
Javascript.  Many such validators reject + in an email address.  :(

-kgd

Re: Multiple recipient_delimiter address extensions?

[Wietse Venema]

Kris Deugau:
> grarpamp wrote:
> > I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
> > meta issue. Other users migration or dual uses aside, with that
> > one I wanted to but did not have benefit to research whether
> > + or - had better merits. Such as which is in more common use now,
> > which is trending to be more prevalent in the long term. And why?
> > Honestly, best I could come up with was the large - legacy from
> > decade old qmail-like installations, and not requiring the shift key
> > seemed to win, heh :) I'm sure there are more sound thoughts
> > on the matter in a paper somewhere.
> 
> - has the fairly significant advantage of being allowed on more sites
> that try to validate "well-formed" email addresses - often in
> Javascript.  Many such validators reject + in an email address.  :(

It would be relatively easy to implement "truncate the localpart
at the first instance of any character in the delimiter set, then
do one table lookup" (basically, replacing strchr() with strcspn()).

This would allow one to use '-' for some websites and '+' for others.

This could later be made more configurable, for example "for each
delimiter in the specified order: truncate the localpart, do
table lookup, and stop after the first successful lookup".

As long as users stick to names with [a-zA-Z0-9.], the first,
simpler, implementation should be sufficient.

Wietse

Re: Multiple recipient_delimiter address extensions?

[Wietse Venema]

Wietse Venema:
> Kris Deugau:
> > grarpamp wrote:
> > > I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
> > > meta issue. Other users migration or dual uses aside, with that
> > > one I wanted to but did not have benefit to research whether
> > > + or - had better merits. Such as which is in more common use now,
> > > which is trending to be more prevalent in the long term. And why?
> > > Honestly, best I could come up with was the large - legacy from
> > > decade old qmail-like installations, and not requiring the shift key
> > > seemed to win, heh :) I'm sure there are more sound thoughts
> > > on the matter in a paper somewhere.
> > 
> > - has the fairly significant advantage of being allowed on more sites
> > that try to validate "well-formed" email addresses - often in
> > Javascript.  Many such validators reject + in an email address.  :(
> 
> It would be relatively easy to implement "truncate the localpart
> at the first instance of any character in the delimiter set, then
> do one table lookup" (basically, replacing strchr() with strcspn()).
> 
> This would allow one to use '-' for some websites and '+' for others.

Unfortunately this would break existing code that expands
$recipient_delimiter, for example the forward_path default value.

This means using a new parameter name for the recipient delimiter
set, and making the recipient_delimiter default value dependent on
the value of that new parameter (for example take the first character).

Wietse

> This could later be made more configurable, for example "for each
> delimiter in the specified order: truncate the localpart, do
> table lookup, and stop after the first successful lookup".
> 
> As long as users stick to names with [a-zA-Z0-9.], the first,
> simpler, implementation should be sufficient.
> 
>   Wietse
> 

Re: Delivery to command in aliases ignored ?

[Charles Marcus]

On 2013-04-01 10:21 AM, Kajetan Dolinar  wrote:
By a detailed and systematic search into my main.cf , 
I have found out that I had a stale alias_maps setting somewhere in 
the bushes amidst the comments and other settings. The first setting 
in the file was the correct setting (doing the mailman job) and the 
second one was the stale one, which remained valid in the runtime of 
the local process. I appologize for the confusion.


This is *precisely* why you should always use postconf -n output (both 
for your *own* troubleshooting efforts, as well as for when asking for 
help here).


Using postcinf -n would have shown you immediately (before you even got 
to the point of asking for help here) your problem.


Incidentally, this is why I always leave the original main.cf as is and 
append *all* of my custom settings to the very end of the file...


--

Best regards,

Charles

Re: Delivery to command in aliases ignored ?

[Reindl Harald]

Am 04.04.2013 20:35, schrieb Charles Marcus:
> On 2013-04-01 10:21 AM, Kajetan Dolinar  wrote:
>> By a detailed and systematic search into my main.cf , I have 
>> found out that I had a stale
>> alias_maps setting somewhere in the bushes amidst the comments and other 
>> settings. The first setting in the file
>> was the correct setting (doing the mailman job) and the second one was the 
>> stale one, which remained valid in the
>> runtime of the local process. I appologize for the confusion.
> 
> This is *precisely* why you should always use postconf -n output (both for 
> your *own* troubleshooting efforts, as
> well as for when asking for help here).
> 
> Using postcinf -n would have shown you immediately (before you even got to 
> the point of asking for help here) your
> problem.
> 
> Incidentally, this is why I always leave the original main.cf as is and 
> append *all* of my custom settings to the
> very end of the file...

or if you want a REALLY clean "main.cf" copy the shipped somewhere in
a docs folder and write a COMPLETE own which is EXPLICIT

see below a example which is clear and does not need any comment line, well
this is a setup which does not provide smtp on the network but any other of
my machines looks identical with a smtpd-block after the smtp-ones

why should i want any random line in a servers config which was not
explicitly written by myself which implicates i understand it independent
if we speak about postfix, dovecot, mysql, apache?

myhostname  = 
mydomain= 
myorigin= $mydomain
mynetworks  = 127.0.0.0/8
smtpd_banner= $myhostname ESMTP
mail_name   = MTA

relayhost   = [my-relayhost]:587
smtp_sasl_auth_enable   = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

smtp_use_tls= yes
smtp_tls_loglevel   = 1
smtp_tls_cert_file  = /etc/postfix/certs/localhost.pem
smtp_tls_key_file   = /etc/postfix/certs/localhost.pem
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_security_level = may
smtp_tls_note_starttls_offer= yes
smtp_tls_session_cache_timeout  = 3600s
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache

enable_long_queue_ids   = yes
smtpd_discard_ehlo_keywords = silent-discard, etrn, dsn, vrfy, 
enhancedstatuscodes
smtpd_relay_restrictions= permit_mynetworks, 
permit_sasl_authenticated, defer_unauth_destination
smtpd_recipient_limit   = 500
disable_vrfy_command= yes

mydestination   =
alias_maps  = hash:/etc/aliases
alias_database  = hash:/etc/aliases
sender_canonical_maps   = hash:/etc/postfix/canonical

double_bounce_sender= double-bounce@
address_verify_sender   = postmaster@
empty_address_recipient = postmaster@
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code= 550
unknown_hostname_reject_code= 501
unknown_address_reject_code = 550
bounce_template_file= /etc/postfix/bounce.cf
message_size_limit  = 10485760

body_checks_size_limit  = 1024
in_flow_delay   = 0
queue_run_delay = 300
minimal_backoff_time= 900
maximal_backoff_time= 3600
inet_protocols  = ipv4

readme_directory = /usr/share/doc/postfix-2.10.0/README_FILES
sample_directory = /usr/share/doc/postfix-2.10.0/samples
sendmail_path = /usr/sbin/sendmail
html_directory = no
setgid_group = postdrop
manpage_directory = /usr/share/man
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix



signature.asc
Description: OpenPGP digital signature

Re: Verify cache dump

[Nikolaos Milas]

On 4/4/2013 5:42 μμ, Wietse Venema wrote:


How long is your expected downtime? Even it someone receives only
one email per week, they should expire in 24 days.


It will be around 5-6 hours. I would like to avoid the gateway server 
bouncing mails due to not being able to verify the recipients.


Ideally, mails should be accepted by the gateway server based on its 
verify cache, and then kept in the queue during the main server downtime 
period.


One solution would be to delete the verify_cache.db file NOW and thus 
force the creation of a new one, so that any positive cached address 
will be added and be valid for at least 7 days (provided that the 
downtime will occur in the next 7 days); the only drawback - I think - 
is that some addresses may not be used until the downtime occurs, so 
they will be missing from the verify cache when the downtime occurs.


One way to solve this would be to send one mail to all our users, so 
that they will be added to the verify cache. However there are multiple 
addresses per user (due to aliases, so this complicates things a bit).


If we use a group alias like all-st...@example.com as a recipient 
address, does that cause all of the true recipient addresses (that the 
alias resolves to) to be added to the verify cache as well?


Or, can we manually add addresses to the verify cache?

Alternatively, we could switch to ldap-based verification during this 
period - but I would like to avoid doing serious changes under pressure.


Thanks,
Nick

Re: Delivery to command in aliases ignored ?

[Wietse Venema]

Charles Marcus:
> On 2013-04-01 10:21 AM, Kajetan Dolinar  wrote:
> > By a detailed and systematic search into my main.cf , 
> > I have found out that I had a stale alias_maps setting somewhere in 
> > the bushes amidst the comments and other settings. The first setting 
> > in the file was the correct setting (doing the mailman job) and the 
> > second one was the stale one, which remained valid in the runtime of 
> > the local process. I appologize for the confusion.
> 
> This is *precisely* why you should always use postconf -n output (both 
> for your *own* troubleshooting efforts, as well as for when asking for 
> help here).
> 
> Using postconf -n would have shown you immediately (before you even got 
> to the point of asking for help here) your problem.
> 
> Incidentally, this is why I always leave the original main.cf as is and 
> append *all* of my custom settings to the very end of the file...

Postfix has improved over time but it does not warn about multiple
entries for the same parameter. It probably should warn, especially
when multiple entries for the same parameter have different values.

Wietse

Re: Verify cache dump

[Wietse Venema]

Nikolaos Milas:
> On 4/4/2013 5:42 ??, Wietse Venema wrote:
> 
> > How long is your expected downtime? Even it someone receives only
> > one email per week, they should expire in 24 days.
> 
> It will be around 5-6 hours. I would like to avoid the gateway server 
> bouncing mails due to not being able to verify the recipients.

With the existing automatic cache refresh after 7 days,

- ALL recipients who received their last email less than 1 week ago will
  remain cached for 24-31 days.

- ALL recipients who received their last email 1-2 weeks ago will remain
  cached for 17-24 days.

- ALL recipients who received their last email 2-3 weeks ago will remain
  cached for 10-17 days.

> One solution would be to delete the verify_cache.db file NOW and thus

NO, THAT WOULD BE AN ENORMOUS MISTAKE.

You weren't paying attention when i explained automatic cache refresh.

Wietse

Re: Verify cache dump

[Nikolaos Milas]

On 4/4/2013 11:06 μμ, Wietse Venema wrote:


You weren't paying attention when i explained automatic cache refresh.


I admit I was confused with the initial explanation.

Your latest clarifications make things much clearer to me.

I understand that the gateway server should work fine with the current 
(default) verify cache settings during the scheduled downtime.


Thanks,
Nick

Re: Multiple recipient_delimiter address extensions?

[Wietse Venema]

I've done a proof-of-concept implementation that works as documented
below the signature.

This retains the old recipient_delimiter parameter because that
parameter has been in use since 19981029 in the forward_path default
parameter value, and I can't have a multi-character value there.

To support users that have .forward+foo and .forward-foo, you'd
have to spell the file names explicitly:

/etc/postfix/main.cf:
recipient_delimiters = +-
forward_path = 
$home/.forward+${extension}, 
$home/.forward-${extension}, 
$home/.forward

This works regardless of what the delimiter in the email address
was; Postfix does not use that when it searches forward_path.

Wietse

recipient_delimiters (default: $recipient_delimiter)
The set of characters that can separate user names and
address extensions (user+foo).  See canonical(5),
local(8), relocated(5) and virtual(5) for the effects
this has on aliases, canonical, virtual, and relocated
lookups.  Basically, the software tries user+foo before
trying user.

When the recipient_delimiters set contains multiple
characters, user names and address extensions are
separated at the first character that matches the
recipient_delimiters set.  The implementation recognizes
only one delimiter character per email address.

By default, the recipient_delimiter (note: singular)
value equals the first character of the recipient_delimiters
parameter value.  The recipient_delimiter parameter is
used in the default forward_path value, where the
software tries .forward+foo before trying .forward.

When the recipient_delimiters parameter is not specified,
its value defaults to the recipient_delimiter value.

Example:

# Handle both Postfix and qmail extensions.
recipient_delimiters = +-