Re: smtp_tls_policy_maps: Restrict CA certs

2014-10-26 Thread Michael Ströder 
Viktor Dukhovni wrote:
> Note, when you "pin" the issuer if a domain's certificate chain
> you have the luxury of more time between updates, but eventually
> the site will obtain a certificate from some other CA or a new
> issuer key from the same CA. 

Yupp. I'm aware of that. For those sites I'm getting informed.

But thanks for reminding in the general case.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Backscatter spam issue

2014-10-26 Thread Isaac Grover 
Good morning all,

It seems that blocking backscatter is an issue that plenty of folks are
talking about but working solutions are vague and rare.  Our single MTA
running Postfix 2.11.0 does an okay job at blocking spam, but backscatter
is a known problem that we were made aware of when Gmail was rate limiting
mail forwarded from our server.

Other than cryptic header checks and the guide at
http://www.backscatterer.org/?target=usage which appears to have blocked
legitimate mail when we implemented it, are there any working
configurations that successfully reject/drop backscatter spam?  Shown below
is our postconf -n.


[root@mail ~]# uname -a
Linux [REMOVED] 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31 17:20:51 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
[root@mail ~]# postconf -d | grep mail_version
mail_version = 2.11.0
milter_macro_v = $mail_name $mail_version
[root@mail ~]# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
dovecot_destination_recipient_limit = 1
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 3072
milter_default_action = accept
mydestination = $myhostname, localhost, localhost.localdomain,
localhost.$mydomain
myhostname = mail.qcshosting.net
mynetworks = 127.0.0.0/8, [REMOVED]/32
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600s
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*3
bl.spameatingmonkey.net*2 bl.spamcop.net*2 dnsbl.sorbs.net*2 db.wpbl.info*2
all.rbl.jp ix.dnsbl.manitu.net dnsrbl.swinog.ch spamtrap.trblspam.com
swl.spamhaus.org*-4
postscreen_dnsbl_threshold = 3
postscreen_greet_action = enforce
postscreen_greet_banner =
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
$smtpd_sender_login_maps
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unknown_client, reject_unknown_reverse_client_hostname, permit
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_invalid_hostname, reject_non_fqdn_hostname, permit
smtpd_milters = inet:127.0.0.1:8891
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_unauth_destination,
reject_unknown_recipient_domain, check_client_access
hash:/etc/postfix/rbl_override_whitelist, check_policy_service
unix:private/policyd-spf
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = $virtual_mailbox_maps
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks,
reject_unknown_sender_domain, reject_authenticated_sender_login_mismatch,
permit
smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem
smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
smtpd_tls_security_level = may
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
unknown_local_recipient_reject_code = 550
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwarders.cf,
proxy:mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_transport = dovecot
virtual_uid_maps = static:5000
[root@mail ~]#


Isaac Grover

[slightly OT] Spam and PostFix header_checks

2014-10-26 Thread Stephen Satchell 
Spam has many sources, as we all know.  Mr. Verma stated earlier this
month that header_checks should not be used for spam filtering...and I
found that my mine was out of control, particularly with Subjects, for
just that purpose.  Not to mention that the effectiveness of the many,
many checks has dropped, and many of the blocks had outlived their
usefulness.

I run a fairly large number of mailboxes of my own on my PostFix server,
some of which have for one reason or another turned into spam-traps.  So
I decided to utilize these bits of flypaper and start shutting off the
worst of these spammers at my edge router, instead of letting them in
the front door.  Also, I'm working on the theory that "people who let
out organized spam most likely have other bad habits."

Why?  I started noticing that the majority of spam that was getting past
Spamhaus and my Subject Sieve came from small sub-nets.  In addition to
the ssh abusers and ShellShock attackers, I started adding these
spamming sub-nets to my ACLs.  As the list grew, the volume of spam
dropped like crazy.

But wait!  As I said, I had this insane header_checks file.  All kinds
of weird regular expressions to try to catch these spammers...and the
spammers did what spammer do, regularly change their subject lines and
do interesting subtle substitutions to get past content filters.  (I
won't catalog the substitutions here.)

So I started to remove subject-field checks, little by little. After I
dropped about 130 subject checks early on in the process, I didn't
noticed any significant increase in spam volume.  The process continues;
I'm now down to a 126-line header_checks file, and dropping.

What will I keep:
  *  To: fields that are nonsense
  *  From: fields like FBI, CIA, IRS, t...@live.com, my PTR
  *  Subjects:  excessive spaces, ESC. certain keywords, phrases
  *  Subject: still popular with web-form abusers
  *  Certain checks that block web-form abuse effectively

For what it's worth, my daily log-check shows that PostFix is blocking a
moderate number of mail messages via SpamHaus, but header_check blocking
has dropped considerably.  How effective has this process been?  For the
past four days, I've had five (5) spam messages.  Before I started
aggressively blocking mail-abuse subnets, I was getting about 150 per day.

Re: [slightly OT] Spam and PostFix header_checks

2014-10-26 Thread li...@rhsoft.net 



Am 26.10.2014 um 14:25 schrieb Stephen Satchell:

What will I keep:
   *  To: fields that are nonsense
   *  From: fields like FBI, CIA, IRS, t...@live.com, my PTR
   *  Subjects:  excessive spaces, ESC. certain keywords, phrases
   *  Subject: still popular with web-form abusers
   *  Certain checks that block web-form abuse effectively

For what it's worth, my daily log-check shows that PostFix is blocking a
moderate number of mail messages via SpamHaus, but header_check blocking
has dropped considerably.  How effective has this process been?  For the
past four days, I've had five (5) spam messages.  Before I started
aggressively blocking mail-abuse subnets, I was getting about 150 per day


forget about single RBL's, they are on one hand very error-prone and 
only catch a part - instead implement postscreen with a reasonable 
scoring and you drop around 90-95% of all junk


with the config below you reject if the summary is 8 or higher, have 
some whitelists in the mix and the greet-action alone blocks a 
noticeable part of junk, postscreen_greet_wait enforces a wait delay for 
new clients and maybe over the time you are no longer attractive as target


http://www.postfix.org/POSTSCREEN_README.html

postscreen_dnsbl_ttl = 10m
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_greet_wait = ${stress?3}${stress:10}s
postscreen_dnsbl_sites =
 dnsbl.sorbs.net=127.0.0.10*8
 zen.spamhaus.org=127.0.0.[10;11]*8
 b.barracudacentral.org=127.0.0.2*7
 dnsbl.inps.de=127.0.0.2*7
 dnsbl.sorbs.net=127.0.0.5*6
 zen.spamhaus.org=127.0.0.[4..7]*6
 bl.mailspike.net=127.0.0.[2;10;11;12]*4
 bl.spamcop.net=127.0.0.2*4
 bl.spameatingmonkey.net=127.0.0.[2;3]*4
 zen.spamhaus.org=127.0.0.3*4
 dnsrbl.swinog.ch=127.0.0.3*4
 dnsbl-1.uceprotect.net=127.0.0.2*3
 ix.dnsbl.manitu.net=127.0.0.2*3
 psbl.surriel.com=127.0.0.2*3
 zen.spamhaus.org=127.0.0.2*3
 dnsbl.sorbs.net=127.0.0.7*3
 dnsbl.sorbs.net=127.0.0.8*2
 dnsbl-2.uceprotect.net=127.0.0.2*2
 dnsbl.sorbs.net=127.0.0.6*2
 dnsbl.sorbs.net=127.0.0.9*2
 dnsbl-backscatterer.thelounge.net=127.0.0.2*1
 wl.mailspike.net=127.0.0.[18;19;20]*-2
 ips.whitelisted.org=127.0.0.2*-2
 list.dnswl.org=127.0.[0..255].0*-2
 list.dnswl.org=127.0.[0..255].1*-3
 list.dnswl.org=127.0.[0..255].2*-4
 list.dnswl.org=127.0.[0..255].3*-5

queue message when lmtp link to remote server is down

2014-10-26 Thread ferriswheel 
hello,

currently using postifix version 2.5.1

how do i configure lmtp to keep a  message queue when the outgoing link is down 


TIA and regards

Re: queue message when lmtp link to remote server is down

2014-10-26 Thread Viktor Dukhovni 
On Mon, Oct 27, 2014 at 12:22:22PM +1100, ferriswheel wrote:

> Currently using postifix version 2.5.1
> 
> How do I configure lmtp to keep a message queued when the outgoing link is 
> down 

As opposed to what?

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

Logs of behaviour you don't want, less cryptic explanation of what
you do want.

-- 
Viktor.

Re: queue message when lmtp link to remote server is down

2014-10-26 Thread li...@rhsoft.net 


Am 27.10.2014 um 02:22 schrieb ferriswheel:

currently using postifix version 2.5.1
how do i configure lmtp to keep a  message queue when the outgoing link is down


uhm there is nothing to configure

a message keeps queued until it is delivered and even if the lmtpd 
daemon crashs until it responded with success it still get queued and 
maybe delivered more than once (what is even logged in that case)


2.5.1 is stoneold but that behavior i guess is default for decades since 
lmtp is practically the same as smtp

Re: queue message when lmtp link to remote server is down

2014-10-26 Thread ferriswheel 
On Mon, 27 Oct 2014 01:30:42 +
Viktor Dukhovni  wrote:

> On Mon, Oct 27, 2014 at 12:22:22PM +1100, ferriswheel wrote:
> 
> > Currently using postifix version 2.5.1
> > 
> > How do I configure lmtp to keep a message queued when the outgoing link is 
> > down 
> 
> As opposed to what?
> 
> http://www.postfix.org/DEBUG_README.html#mail
> 
> Logs of behaviour you don't want, less cryptic explanation of what
> you do want.
> 
> -- 
>   Viktor.


hello,

thanks for your reply.


i'll re-word the question.

can postfix hold messages in a queue when the lmtp link has failed to another 
server.?

the following is a sanitised log entry 


Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: connect to X.X.X.X:22424: No route 
to host
Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: 579032410732: 
to=, relay=none, delay=3.1, delays=0.04/0/3/0, dsn=4.4.1, 
status=deferred (connect to Y.Y.Y.Y:22424: No route to host)
Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: from=<>, 
status=expired, returned to sender
Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: removed

regards
john

's' modifier is not working in body_checks

2014-10-26 Thread Dr Michael Daly 
Hi
The 's' modifier is not working in a body_checks regex entry within
postfix 2.11.1, but it does work in an online regex checker eg regex101:

/((?=.*website)|(?=.*mywebsite\.com\.au))((?=.*purchase)|(?=.*great)).*/s
REJECT

eg a test file is REJECTED if it has contents:
website great
but in my postfix it is NOT rejected if the two words in the test file are
separated by a carriage return:
website
great

(am testing via:
postmap -q - pcre:/etc/postfix/body_checks < /etc/postfix/testfile

Thanks
Michael

Re: Backscatter spam issue

2014-10-26 Thread Noel Jones 
On 10/26/2014 8:01 AM, Isaac Grover wrote:
> Good morning all,
> 
> It seems that blocking backscatter is an issue that plenty of folks
> are talking about but working solutions are vague and rare.  Our
> single MTA running Postfix 2.11.0 does an okay job at blocking spam,
> but backscatter is a known problem that we were made aware of when
> Gmail was rate limiting mail forwarded from our server.

It's unclear if you're referring to your server as a source of
backscatter -- thus getting blacklisted -- or a victim of
backscatter, also called a joe-job.

If you're the source -- meaning you're sending out postmaster
notices of undeliverable mail -- don't accept undeliverable mail.
In particular, don't use wildcard rewrites in virtual or canonical
tables, and don't accept mail for non-existent users.

If you're the victim -- you're receiving non-delivery notices for
mail that didn't originate from your server -- the header checks
examples in the postfix BACKSCATTER_README are safe and fairly
effective. Of course you have to adjust them for your own domain.

http://www.postfix.org/BACKSCATTER_README.html


If you need more help or don't understand the examples, you'll need
to provide more details, including log entries.



  -- Noel Jones



> 
> Other than cryptic header checks and the guide at
> http://www.backscatterer.org/?target=usage which appears to have
> blocked legitimate mail when we implemented it, are there any
> working configurations that successfully reject/drop backscatter
> spam?  Shown below is our postconf -n.
> 
> 
> [root@mail ~]# uname -a
> Linux [REMOVED] 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31
> 17:20:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> [root@mail ~]# postconf -d | grep mail_version
> mail_version = 2.11.0
> milter_macro_v = $mail_name $mail_version
> [root@mail ~]# postconf -n
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> broken_sasl_auth_clients = yes
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = amavisfeed:[127.0.0.1]:10024
> daemon_directory = /usr/libexec/postfix
> data_directory = /var/lib/postfix
> debug_peer_level = 2
> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
> ddd $daemon_directory/$process_name $process_id & sleep 5
> dovecot_destination_recipient_limit = 1
> html_directory = no
> inet_interfaces = all
> inet_protocols = ipv4
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> message_size_limit = 3072
> milter_default_action = accept
> mydestination = $myhostname, localhost, localhost.localdomain,
> localhost.$mydomain
> myhostname = mail.qcshosting.net 
> mynetworks = 127.0.0.0/8 , [REMOVED]/32
> newaliases_path = /usr/bin/newaliases.postfix
> non_smtpd_milters = $smtpd_milters
> policyd-spf_time_limit = 3600s
> postscreen_access_list = permit_mynetworks,
> cidr:/etc/postfix/postscreen_access.cidr
> postscreen_blacklist_action = drop
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = zen.spamhaus.org
> *3 b.barracudacentral.org
> *3 bl.spameatingmonkey.net
> *2 bl.spamcop.net
> *2 dnsbl.sorbs.net *2
> db.wpbl.info *2 all.rbl.jp 
> ix.dnsbl.manitu.net  dnsrbl.swinog.ch
>  spamtrap.trblspam.com
>  swl.spamhaus.org
> *-4
> postscreen_dnsbl_threshold = 3
> postscreen_greet_action = enforce
> postscreen_greet_banner =
> proxy_read_maps = $local_recipient_maps $mydestination
> $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps
> $virtual_mailbox_domains $relay_recipient_maps $relay_domains
> $canonical_maps $sender_canonical_maps $recipient_canonical_maps
> $relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
> sample_directory = /usr/share/doc/postfix-2.6.6/samples
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtpd_banner = $myhostname ESMTP $mail_name
> smtpd_client_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_unknown_client,
> reject_unknown_reverse_client_hostname, permit
> smtpd_data_restrictions = reject_unauth_pipelining
> smtpd_delay_reject = yes
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_invalid_hostname,
> reject_non_fqdn_hostname, permit
> smtpd_milters = inet:127.0.0.1:8891 
> smtpd_recipient_restrictions = permit_sasl_authenticated,
> permit_mynetworks, reject_unauth_destination,
> reject_unknown_recipient_domain, check_client_access
> hash:/etc/postfix/rbl_override_whitelist, check_policy_service
> unix

Re: queue message when lmtp link to remote server is down

2014-10-26 Thread Noel Jones 
On 10/26/2014 8:54 PM, ferriswheel wrote:
> On Mon, 27 Oct 2014 01:30:42 +
> Viktor Dukhovni  wrote:
> 
>> On Mon, Oct 27, 2014 at 12:22:22PM +1100, ferriswheel wrote:
>>
>>> Currently using postifix version 2.5.1
>>>
>>> How do I configure lmtp to keep a message queued when the outgoing link is 
>>> down 
>>
>> As opposed to what?
>>
>> http://www.postfix.org/DEBUG_README.html#mail
>>
>> Logs of behaviour you don't want, less cryptic explanation of what
>> you do want.
>>
>> -- 
>>  Viktor.
> 
> 
> hello,
> 
> thanks for your reply.
> 
> 
> i'll re-word the question.
> 
> can postfix hold messages in a queue when the lmtp link has failed to another 
> server.?
> 
> the following is a sanitised log entry 
> 
> 
> Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: connect to X.X.X.X:22424: No 
> route to host
> Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: 579032410732: 
> to=, relay=none, delay=3.1, delays=0.04/0/3/0, dsn=4.4.1, 
> status=deferred (connect to Y.Y.Y.Y:22424: No route to host)
> Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: from=<>, 
> status=expired, returned to sender


status=expired after 3 seconds??? Don't use such a short queue lifetime!





> Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: removed
> 
> regards
> john
>

Re: 's' modifier is not working in body_checks

2014-10-26 Thread Noel Jones 
On 10/26/2014 9:08 PM, Dr Michael Daly wrote:
> Hi
> The 's' modifier is not working in a body_checks regex entry within
> postfix 2.11.1, but it does work in an online regex checker eg regex101:
> 
> /((?=.*website)|(?=.*mywebsite\.com\.au))((?=.*purchase)|(?=.*great)).*/s
> REJECT
> 
> eg a test file is REJECTED if it has contents:
> website great
> but in my postfix it is NOT rejected if the two words in the test file are
> separated by a carriage return:
> website
> great
> 
> (am testing via:
> postmap -q - pcre:/etc/postfix/body_checks < /etc/postfix/testfile
> 
> Thanks
> Michael
> 

As documented, postfix header_checks and body_checks process message
input one line at a time.  Expressions cannot span multiple lines.

For full-body matching, you'll need to use a content filter or milter.


  -- Noel Jones

Re: queue message when lmtp link to remote server is down

2014-10-26 Thread ferriswheel 
On Mon, 27 Oct 2014 02:37:00 +0100
"li...@rhsoft.net"  wrote:

> 
> Am 27.10.2014 um 02:22 schrieb ferriswheel:
> > currently using postifix version 2.5.1
> > how do i configure lmtp to keep a  message queue when the outgoing link is 
> > down
> 
> uhm there is nothing to configure
> 
> a message keeps queued until it is delivered and even if the lmtpd 
> daemon crashs until it responded with success it still get queued and 
> maybe delivered more than once (what is even logged in that case)
> 
> 2.5.1 is stoneold but that behavior i guess is default for decades since 
> lmtp is practically the same as smtp


hello,

thanks for you reply.


the postfix lmtp process in this situation has nothing to connect to, as the 
destination is not listening.

as shown in this sanitised log entry the qmgr process is told to give up as 
status=expired


   Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: connect to X.X.X.X:22424: No 
route to host 
   Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: 579032410732: 
to=, relay=none, delay=3.1, delays=0.04/0/3/0, dsn=4.4.1, 
status=deferred (connect to Y.Y.Y.Y:22424: No route to host)
   Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: from=<>, 
status=expired, returned to sender
   Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: removed


regards

john

Re: queue message when lmtp link to remote server is down

2014-10-26 Thread li...@rhsoft.net 


Am 27.10.2014 um 03:38 schrieb ferriswheel:

On Mon, 27 Oct 2014 02:37:00 +0100
"li...@rhsoft.net"  wrote:


Am 27.10.2014 um 02:22 schrieb ferriswheel:

currently using postifix version 2.5.1
how do i configure lmtp to keep a  message queue when the outgoing link is down


uhm there is nothing to configure

a message keeps queued until it is delivered and even if the lmtpd
daemon crashs until it responded with success it still get queued and
maybe delivered more than once (what is even logged in that case)

2.5.1 is stoneold but that behavior i guess is default for decades since
lmtp is practically the same as smtp


the postfix lmtp process in this situation has nothing to connect to, as the 
destination is not listening.


so what - that happens all day long in case of smtp


as shown in this sanitised log entry the qmgr process is told to give up as 
status=expired

Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: connect to X.X.X.X:22424: No 
route to host
Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: 579032410732: 
to=, relay=none, delay=3.1, delays=0.04/0/3/0, dsn=4.4.1, 
status=deferred (connect to Y.Y.Y.Y:22424: No route to host)
Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: from=<>, 
status=expired, returned to sender
Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: removed


status=expired?

sounds like you have f**d up "maximal_queue_lifetime" which is normally 
5 days and that is why you should always post "postconf -n" output as 
you where directed to debug-readme in the first reply


[root@rh:~]$ postconf -n maximal_queue_lifetime
maximal_queue_lifetime = 3d

[root@rh:~]$ postconf -d maximal_queue_lifetime
maximal_queue_lifetime = 5d

Re: queue message when lmtp link to remote server is down

2014-10-26 Thread ferriswheel 
On Mon, 27 Oct 2014 04:09:09 +0100
"li...@rhsoft.net"  wrote:

> 
> Am 27.10.2014 um 03:38 schrieb ferriswheel:
> > On Mon, 27 Oct 2014 02:37:00 +0100
> > "li...@rhsoft.net"  wrote:
> >>
> >> Am 27.10.2014 um 02:22 schrieb ferriswheel:
> >>> currently using postifix version 2.5.1
> >>> how do i configure lmtp to keep a  message queue when the outgoing link 
> >>> is down
> >>
> >> uhm there is nothing to configure
> >>
> >> a message keeps queued until it is delivered and even if the lmtpd
> >> daemon crashs until it responded with success it still get queued and
> >> maybe delivered more than once (what is even logged in that case)
> >>
> >> 2.5.1 is stoneold but that behavior i guess is default for decades since
> >> lmtp is practically the same as smtp
> >
> > the postfix lmtp process in this situation has nothing to connect to, as 
> > the destination is not listening.
> 
> so what - that happens all day long in case of smtp
> 
> > as shown in this sanitised log entry the qmgr process is told to give up as 
> > status=expired
> >
> > Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: connect to X.X.X.X:22424: 
> > No route to host
> > Oct 20 07:45:52 pilot mail_pilot/lmtp[5624]: 579032410732: 
> > to=, relay=none, delay=3.1, delays=0.04/0/3/0, dsn=4.4.1, 
> > status=deferred (connect to Y.Y.Y.Y:22424: No route to host)
> > Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: from=<>, 
> > status=expired, returned to sender
> > Oct 20 07:45:52 pilot mail_pilot/qmgr[4951]: 579032410732: removed
> 
> status=expired?
> 
> sounds like you have f**d up "maximal_queue_lifetime" which is normally 
> 5 days and that is why you should always post "postconf -n" output as 
> you where directed to debug-readme in the first reply
> 
> [root@rh:~]$ postconf -n maximal_queue_lifetime
> maximal_queue_lifetime = 3d
> 
> [root@rh:~]$ postconf -d maximal_queue_lifetime
> maximal_queue_lifetime = 5d


hello,


thanks for your reply.


yes, that was the problem.

maximal_queue_lifetime and bounce_queue_lifetime were set to '0'


regards

john