Re: Deprecated: white is better than black

[john]

"...should we not consider the class of disallowed out there to be 
inherently persecuted..."


Why? Are you suggesting the devs try and precog, Minority Report style, 
what nomenclature might in the future be at issue?


“Variable naming is a wide ranging philosophical issue”

It really shouldn’t be - at least not in relation to society and 
oppression.


“…fixing racism…”

In what regard?  Changing variable or logging nomenclature does not fix 
anything related to racism as it exists in society with real people, not 
config\log files, being impacted in their daily lives.  People-of-color 
are not more or less oppressed due to the recent changes in PF.


Notwithstanding the right of devs to use whatever nomenclature they 
desire, those choices should not be taken as any measure of social 
justice...



On 2021-02-24 21:34, John Dale wrote:

If we were to change the nomenclature to something like "disallowed"
and "allowed", should we not consider the class of disallowed out
there to be inherently persecuted?  Are we looking at choosing
variable names with no corresponding representation in the dictionary
(just in case)?  var lkjsfal = "Hello, Hell.";

Variable naming is a wide ranging philosophical issue ..

I for one am very glad we're fixing racism (actually, we may have
fixed it already).



On 2/24/21 3:18 PM, j...@nunyuh.net wrote:
I've purposefully held off on responding to any of this but if the 
devs\list-owners are fine with the community converting this into a 
forum about race + software & computer terms, albeit temporarily, then 
fine - let's "damn the torpedos & full steam ahead" this baby and get 
to work...


We all ready?


On 2021-02-24 16:57, Emmett Culley wrote:

On 2/24/21 12:40 PM, Dirk Stöcker wrote:

On Wed, 24 Feb 2021, Wietse Venema wrote:


Postfix version 3.6 deprecates terminology that implies white is
better than black. Instead, Postfix prefers 'allowlist', 
'denylist',

and variations on those words.


We had a late start, but it seems Newspeak will be established until 
2050 as originally intended by ministery of truth.


Doubleplusgood!

Ciao

What it the problem people seem to have with honest attempts to
address systemic racism in the world and the US especially.  We can
expect NOTHING to change if we take a "I couldn't be bothered"
attitude.

I can only assume that if you are complaining about someone else's
attempt to begin taking action, then you are a racist.  If not, then 
I

apologize.  But only if you are not.

Yes, it took some effort to make these recent changes, and All I can
say is thank you for doing that!

Emmett

Re: Deprecated: white is better than black

[john]

"...other folks could go take a hike..."

Indeed they could - just as they can now...

"So, whose code is it?"

The 'they' that own it...in this specific case, my guess is Wietse...

"...who organically came to the terms white/black list..."

Or really believe that context truly matters which leads them to 
understand that white & black in a piece of software config or log file 
has nothing to do with past or present social abuses and the quest for 
justice...



On 2021-02-24 21:53, John Dale wrote:

"the right of devs to use whatever nomenclature they desire"

That's it.  That's the thing.  I suppose if it was my code and I
wanted to make that change other folks could go take a hike.

So, whose code is it?

If it were my code and I were dead (interesting prospect), I would try
to lay curses from the afterlife on those who would so arrogantly
rewrite my legacy (for better or for worse).  I suppose that also
applies to the millions of humans who organically came to the terms
white/black list.

The dev that overrides all of them is a (or feels like a) God
(pronounced in a Wharf voice "GOD!")


On 2/24/21 7:47 PM, j...@nunyuh.net wrote:

the right of devs to use whatever nomenclature they desire

Re: DKIM Signing (postfix + amavis-new)

[John]

After some interesting experiences using a less than stellar communications 
(I didn't appreciate just how lucky I am to live in a big city until this 
trip) I have managed to get things setup and working.


Because of the poor communications I decided to use the families server as 
a guinea pig.

I reconfigured it to be fairly close to the eventual target system as possible.
I made the changes that Noel suggested and it appears to be working.
The original problem with DKIM ... seem to be resolved.

Before I attempt to modify the eventual target system can someone take a 
look at the attached main and master postconf outputs. My main concern is 
that I have left something important out, not that I will not appreciate 
suggestions for improvement.




On 3 February, 2016 1:40:10 PM Noel Jones  wrote:


On 2/2/2016 5:53 PM, John A @ KLaM wrote:

If I might ask another peripheraly related and most probably very
dumb question - is it possible to the have the inverse of
"permit_authenticated_users"?
The rules for this outfit are - imap for picking up you mail,
submission (port 587) for sending. So if somebody who can
authenticate themselves turns up on port 25, they are in the wrong
place.


This is commonly handled by not offering AUTH on port 25.  Users who
end up there find sending mail doesn't work, and usually recheck
their settings before calling.

Take all the sasl statements out of main.cf, and add them as -o
options to the "submission" service in master.cf.

Something like:
# main.cf
smtpd_sasl_auth_enable = no

# master.cf
submission  inet  n   -   n  -   -   smtpd
  -o smtpd_enforce_tls=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  ... other stuff you like ...





  -- Noel Jones
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_size_limit = 65536
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 20
delay_warning_time = 12h
disable_vrfy_command = yes
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix/html
mailbox_transport = lmtp:unix:private/dovecot-lmtp
message_size_limit = 32768000
mydestination = localhost, localhost.localdomain, localdomain
mydomain = klam.ca
myhostname = smtp.$mydomain
mynetworks = 127.0.0.0/8, [::1]/128
myorigin = $mydomain
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relocated_maps = hash:/etc/postfix/maps/relocated
smtp_dns_support_level = dnssec
smtp_tls_exclude_ciphers = EXPORT, LOW, IDEA, 3DES, MD5, SRP, PSK, aDSS, kECDH,
kDH, SEED, IDEA, RC2, RC5
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions =
smtpd_data_restrictions = reject_multi_recipient_bounce,
reject_unauth_pipelining
smtpd_error_sleep_time = 5s
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_helo_restrictions =
smtpd_recipient_limit = 128
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_unknown_sender_domain, reject_unknown_recipient_domain,
reject_unauth_destination, check_recipient_access
pcre:/etc/postfix/maps/recipient_checks.pcre, check_recipient_access
hash:/etc/postfix/maps/recipient_checks, check_helo_access
pcre:/etc/postfix/maps/helo_checks.pcre, check_sender_access
hash:/etc/postfix/maps/sender_checks, check_policy_service
inet:127.0.0.1:10023, reject_rbl_client zen.spamhaus.org, reject_rbl_client
bl.spamcop.net
smtpd_relay_restrictions = reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_sender_restrictions =
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /root/ssl/certs/$mydomain.mail.pem
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = EXPORT, LOW, IDEA, 3DES, MD5, SRP, PSK, aDSS, kECDH,
kDH, SEED, IDEA, RC2, RC5
smtpd_tls_key_file = /root/ssl/private/$mydomain.mail.key
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/maps/transport
vacation_destination_recipient_limit = 1
virtual_alias_maps = proxy:pgsql:/etc/postfix/sql/virtual_alias_map.sql,
proxy:pgsql:/etc/postfix/sql/virtual_alias_domain_map.sql
virtual_mailbox_domains = proxy:pgsql:/etc/postfix/sql/virtual_domain_map.sql
virtual_mailbox_maps = proxy:pgsql:/etc/postfix/sql/virtual_mailbox_map.sql,
proxy:pgsql:/etc/postfix/sql/virtual_alias_domain_mailbox_map.sql
virtual_transport = lmtp:unix:private/dovecot-lmtp
smtp   inet  n   -   n   -   -   smtpd
-o cleanup_service_name=pre-cleanup
pickup fifo  n   -   n   60  1   pickup
-o cleanup_servi

How can/could I redirect based upon sender.

[John]

Is it possible to redirect mail based upon sender.

I need to redirect email from j...@example.com which would normally be sent 
to some...@klam.com to legal@our_lawyers.com and/or ab...@klam.com.


I would like to just block them but they may be needed!

Thanks
John A

Re: Postscreen setup

[John]

On 31/03/2016 5:34 PM, /dev/rob0 wrote:

BTW, regarding the apology, thanks.  It wasn't my thread, but indeed
all of us who use threaded mail readers are affected by "thread
hijacking."

Now a few comments about your config, one of which is a serious
problem ...

On Thu, Mar 31, 2016 at 01:32:02PM -0400, John Allen wrote:

As I expect local user to use submission for sending (as a result
mynetworks is 127.0.0.1 & ::1/128) do I need specify
postscreen_access_list?

I use that to whitelist one site (affiliated with us) and to block
certain undesirable ESP services.


As postscreen does dnsbl lookups do I still need the
reject_rbl_client entries in smtpd_recipient_restrictions? Do the
latter entries do more than the dnsbl entries?

Postscreen is a scoring system; reject_rbl_client is outright
rejection for a DNSBL hit.  It does not hurt to leave them in if
you're sure you don't want any mail from any host on that list.  I
keep a "reject_rbl_client zen.spamhaus.org" in my restrictions, and
then I have an insanely complex mess of restriction classes which
might call other DNSBLs based on recipient domain.


My postscreen setup would be something like:

# postscreen_access_list = permit_mynetworks  do I need this

I have a cidr: lookup there.


postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes

Wietse covered this also: maybe premature on enabling this?


postscreen_blacklist_action = drop
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3
 bl.spameatingmonkey.net*2
 bl.ipv6.spameatingmonkey.net*2
 dnsbl.ahbl.org*2

B!  No!  Absolutely not!!

AHBL is closed and now lists the entire IPv4 Internet space.

BTW I updated my HOWTO, but you seem to be using the old version.
New version is here:

http://rob0.nodns4.us/postscreen.html

"...
Last updated: 2016-01-16

Last changes: updated for Postfix 2.11+, removed AHBL. The previous
version of this document, which did NOT require Postfix 2.11+, can be
seen here: postscreen-old.html, with AHBL left intact! (Let this
serve as a lesson to those who follow online howto documents without
reading and understanding them.)
"


 bl.spamcop.net
 dnsbl.sorbs.net
 swl.spamhaus.org*-4

Spamhaus SWL does not list very many hosts.  I really do recommend
DNSWL.org (and use it for bypassing the after-220 tests with
"postscreen_dnsbl_whitelist_threshold=-1".


smtpd_recipient_restrictions = reject_invalid_hostname,
 reject_non_fqdn_hostname, reject_non_fqdn_sender,

The first two are deprecated syntax, *_helo_hostname


 reject_non_fqdn_recipient,
 reject_unknown_sender_domain, reject_unknown_recipient_domain,
 reject_unauth_destination, reject_unknown_reverse_client_hostname,
 check_recipient_access pcre:/etc/postfix/maps/recipient_checks.pcre,
 check_recipient_access hash:/etc/postfix/maps/recipient_checks,
 check_helo_access pcre:/etc/postfix/maps/helo_checks.pcre,
 check_sender_access hash:/etc/postfix/maps/sender_checks,
 check_policy_service inet:127.0.0.1:10023, reject_rbl_client
 zen.spamhaus.org, reject_rbl_client bl.spamcop.net

I wouldn't reject on Spamcop.  It's an automated list, and the
Spamcop folks will tell you it's best when used in a scoring system.
Your mail, so it's up to you, of course.
Thanks for the heads up on /dnsbl.ahbl.org/. I don't remember reading 
your "how to", had I done so it would probably have saved me some time 
and head scratching.

The list I had proposed was an amalgam of many of the articles I had read.

What I arrived at is:
b.barracudacentral.org=127.0.0.2*7
dnsbl.inps.de=127.0.0.2*7
zen.spamhaus.org=127.0.0.10*8
zen.spamhaus.org=127.0.0.11*8
zen.spamhaus.org=127.0.0.[4..7]*6
zen.spamhaus.org=127.0.0.3*4
zen.spamhaus.org=127.0.0.2*3
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
bl.mailspike.net=127.0.0.2*5
bl.mailspike.net=127.0.0.10*4
bl.mailspike.net=127.0.0.11*4
bl.mailspike.net=127.0.0.12*4
wl.mailspike.net=127.0.0.18*-2
wl.mailspike.net=127.0.0.19*-2
wl.mailspike.net=127.0.0.20*-2
dnsbl.sorbs.net=127.0.0.10*8
dnsbl.sorbs.net=127.0.0.5*6
dnsbl.sorbs.net=127.0.0.7*3
dnsbl.sorbs.net=127.0.0.8*2
dnsbl.sorbs.net=127.0.0.6*2
dnsbl.sorbs.net=127.0.0.9*2

But as I did not understand it or its syntax i decided to use the list 
that L.P.H van Belle used in his February posting.

I will at some future date take a closer look at it.

 new main.cf
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_size_limit = 65536
compatibility_level = 2
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 20
delay_warning_time = 12h
disable_vrfy_command = yes
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix/html
ine

Re: WoSign/StartCom CA in the news

[John]

This may be way off topic, if I apologise.

Looking a the available CAs many of them do not seem to pass the 
/s//niff test//./ WoSign/Startcom are not alone in being found to be 
either incompetent or dishonest. Which made me wonder if there might be 
an alternative to CA issued certs. Is there anyway that DNS/DNSSEC could 
be used to publish and verify certs.


JohnA

//


On 27/09/16 06:29 PM, Viktor Dukhovni wrote:

WoSign (who seemingly purchased StartCom) seem to have run into
some compliance issues as reported by Firefox:


http://arstechnica.com/security/2016/09/firefox-ready-to-block-certificate-authority-that-threatened-web-security/

Many SMTP servers are using certs from StartCom.  In my DANE
adoption survey, out of 2201 certificates used by DANE MX
hosts 411 are issued by StartCom and 47 by WoSign.  So that's
just over 20% of observed certificates.  While the rate is
likely different for the larger SMTP ecosystem (DANE users
are bleeding edge, not representative at this time), I expect
that these CAs are still quite popular overall.

If you're using StartCom/WoSign certs, and rely on them being
verified by MUAs and/or peer MTAs. you may want to make
contingency plans if Mozilla and perhaps others go through
with delisting (or disabling) the related root CAs from
their trusted CA bundles.

Re: Prevention of sending authentication via plaintext on port 25.

[John]

I have submission sasl set as Venema suggests, should/would it a good 
idea to add "smtp_sasl_auth_enable=no" to the smtp entry in master.cf, 
or is the default "good enough".




On 03/12/16 10:10 AM, Wietse Venema wrote:

rich.gre...@hushmail.com:

There are ports that exist for encrypted transfer of this data
(such as 465, 587).  What is the current state of the art for
preventing the user's client software from being able to do this
(sending their authentication details plaintext)?  Is it safe to
simply block this port external to the machine, for example, in
the router?

Don't enable SASL auth on port 25.

Do require smtpd_tls_auth_only=yes on port 587.

This is easiest implemented by seting smtpd_sasl_auth_enable and
smtpd_tls_auth_only in the master.cf entry for the port 587 service,
and not setting them in main.cf.

submission inet n   -   n   -   -   smtpd
   -o syslog_name=postfix/submission
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_sasl_auth_only=yes
   -o smtpd_reject_unlisted_recipient=no
   -o smtpd_client_restrictions=$mua_client_restrictions
   -o smtpd_helo_restrictions=$mua_helo_restrictions
   -o smtpd_sender_restrictions=$mua_sender_restrictions
   -o smtpd_recipient_restrictions=
   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
   -o milter_macro_daemon_name=ORIGINATING

(similar for the obsolete 'smtps' service on port 465).

mua_client_restrictions, mua_helo_restrictions, mua_sender_restrictions
can then be specified in main.cf.

Wietse

Warning: group or other writeable:

[John]

I am seeing the above message associated with the following files -

/usr/lib/postfix/./sbin/lmtp
/usr/lib/postfix/./libpostfix-tls.so.1
/usr/lib/postfix/./libpostfix-util.so.1
/usr/lib/postfix/./libpostfix-dns.so.1
/usr/lib/postfix/./libpostfix-master.so.1
/usr/lib/postfix/./libpostfix-global.so.1
/usr/lib/postfix/sbin/./lmtp

My problem is that I cannot find these files - where should I look and 
why are they group/other writeable?


John A

Re: Warning: group or other writeable: - followup

[John]

Do these errors matter?


On 10/12/16 01:15 AM, John wrote:

I am seeing the above message associated with the following files -

/usr/lib/postfix/./sbin/lmtp
/usr/lib/postfix/./libpostfix-tls.so.1
/usr/lib/postfix/./libpostfix-util.so.1
/usr/lib/postfix/./libpostfix-dns.so.1
/usr/lib/postfix/./libpostfix-master.so.1
/usr/lib/postfix/./libpostfix-global.so.1
/usr/lib/postfix/sbin/./lmtp

My problem is that I cannot find these files - where should I look and 
why are they group/other writeable?


John A

Re: Warning: group or other writeable: - followup

[John]

In the mail log.

I get the error message "Warning: group or other writeable:" followed by 
one of the following file names


/usr/lib/postfix/./sbin/lmtp
/usr/lib/postfix/./libpostfix-tls.so.1
/usr/lib/postfix/./libpostfix-util.so.1
/usr/lib/postfix/./libpostfix-dns.so.1
/usr/lib/postfix/./libpostfix-master.so.1
/usr/lib/postfix/./libpostfix-global.so.1
/usr/lib/postfix/sbin/./lmtp

the message is repeated for each filename.

Do these messages matter, should they be followed up, or are they trivia 
and can be ignored.


If the problem needs to be addressed where should I look as I cannot 
find these files - and why might they be  group/other writeable?


I am running Postfix 3.1.3 under Debian Stretch.

John A

On 10/12/16 09:04 AM, Bastian Blank wrote:

On Sat, Dec 10, 2016 at 08:39:14AM -0500, John wrote:

Do these errors matter?

Where do you see errors?  In the subject you talked about warnings.
Please be precise if you want to describe problems.

Bastian

Re: Warning: group or other writeable: - followup

[John]

I will sit on my hands for the moment and await the official fix.

Thanks Scott



On 10/12/16 01:37 PM, Scott Kitterman wrote:

On December 10, 2016 9:48:38 AM EST, John  wrote:

In the mail log.

I get the error message "Warning: group or other writeable:" followed
by
one of the following file names

/usr/lib/postfix/./sbin/lmtp
/usr/lib/postfix/./libpostfix-tls.so.1
/usr/lib/postfix/./libpostfix-util.so.1
/usr/lib/postfix/./libpostfix-dns.so.1
/usr/lib/postfix/./libpostfix-master.so.1
/usr/lib/postfix/./libpostfix-global.so.1
/usr/lib/postfix/sbin/./lmtp

the message is repeated for each filename.

Do these messages matter, should they be followed up, or are they
trivia
and can be ignored.

If the problem needs to be addressed where should I look as I cannot
find these files - and why might they be  group/other writeable?

I am running Postfix 3.1.3 under Debian Stretch.

It's an issue we're aware of.  I intend to deal with it in the next upload.  
The files that these symlinks point to (in the same directory) do have correct 
permissions.

Scott K

OT? SRV records etc

[John]

How likely is it for a DNS to have SRV records for such things as smtp. 
imap ...
I know that a dumb ? but I am try to guesstimate how big an dewy eyed 
optomist I am being in hoping that they are common practise.

Sanity check - of my postfix setup.

[John]

I am trying to debug a problem with my mail system. I think the problem 
is with Dovecot, or Thunderbird.


However, just to make sure i am not missing something really stupid 
could I get a check on my postfix setup.


TIA

John A

alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_size_limit = 65536
compatibility_level = 2
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 20
delay_warning_time = 12h
disable_vrfy_command = yes
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix/html
inet_protocols = all
mailbox_transport = lmtp:unix:private/dovecot-lmtp
message_size_limit = 32768000
mime_header_checks = pcre:/etc/postfix/maps/mime_header_checks.pcre
mydestination = localhost, localhost.localdomain, localdomain
mydomain = klam.ca
myhostname = smtp.$mydomain
mynetworks = 127.0.0.0/8, [::1]/128
myorigin = $mydomain
postscreen_access_list = permit_mynetworks
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = drop
postscreen_disable_vrfy_command = $disable_vrfy_command
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2
bl.spameatingmonkey.net*2 bl.ipv6.spameatingmonkey.net*2 bl.spamcop.net
dnsbl.sorbs.net psbl.surriel.com bl.mailspike.net swl.spamhaus.org*-4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_whitelist_threshold = -1
postscreen_enforce_tls = $smtpd_enforce_tls
postscreen_greet_action = enforce
postscreen_helo_required = yes
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes
postscreen_use_tls = $smtpd_use_tls
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relocated_maps = hash:/etc/postfix/maps/relocated
smtp_dns_support_level = dnssec
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = DES, MD5, RC2, RC4, RC5, IDEA, SRP, PSK, aDSS,
kECDhe, kECDhr, kDHd, kDHr, SEED, LOW, EXPORT
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions = reject_unknown_reverse_client_hostname,
reject_rbl_client zen.spamhaus.org, reject_rbl_client
b.barracudacentral.org, reject_rbl_client bl.spameatingmonkey.net,
reject_rbl_client bl.ipv6.spameatingmonkey.net, reject_rbl_client
bl.spamcop.net
smtpd_data_restrictions = reject_multi_recipient_bounce,
reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_error_sleep_time = 1s
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname, check_helo_access
pcre:/etc/postfix/maps/helo_checks.pcre
smtpd_recipient_limit = 128
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, check_recipient_access
pcre:/etc/postfix/maps/recipient_checks.pcre, check_recipient_access
hash:/etc/postfix/maps/recipient_checks, check_policy_service
inet:127.0.0.1:10023
smtpd_relay_restrictions = reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, check_sender_access
hash:/etc/postfix/maps/sender_checks
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.klam.ca/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_exclude_ciphers = $smtp_tls_exclude_ciphers
smtpd_tls_key_file = /etc/letsencrypt/live/mail.klam.ca/privkey.pem
smtpd_tls_mandatory_protocols = $smtp_tls_mandatory_protocols
smtpd_tls_protocols = $smtp_tls_protocols
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/maps/transport
virtual_alias_maps = proxy:pgsql:/etc/postfix/sql/virtual_alias_map.sql,
proxy:pgsql:/etc/postfix/sql/virtual_alias_domain_map.sql
virtual_mailbox_domains = proxy:pgsql:/etc/postfix/sql/virtual_domain_map.sql
virtual_mailbox_maps = proxy:pgsql:/etc/postfix/sql/virtual_mailbox_map.sql,
proxy:pgsql:/etc/postfix/sql/virtual_alias_domain_mailbox_map.sql
virtual_transport = lmtp:unix:private/dovecot-lmtp
smtp   inet  n   -   n   -   1   postscreen
smtpd  pass  -   -   n   -   -   smtpd
-o cleanup_service_name=pre-cleanup
pickup fifo  n   -   n   60  1   pickup
-o cleanup_service_name=pre-cleanup
submission inet  n   -   n   -   30  smtpd
-o content_filter=smtp-amavis:[127.0.0.1]:10026
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/dovecot-auth
-o smtpd_sasl_local_domain=$mydomain
-o broken_sasl_auth_clients=yes
-o

Re: Sanity check - of my postfix setup.

[John]

As Andreas pointed out it might help is I outlined the problem.

I am losing mail, it just disappears. Postfix seems to deliver it, hands 
it off the dovecot LMTP and then shows "removed"


Dovecot shows ... : saved to INBOX.

But messages disappear. I am deeply suspicious of the 
Dovecot/Thunderbird sieve setup and have disabled it to see if the 
problem goes away.


When I go through my Postfix config I do not see any problems, but I am 
not a Postfix expert. Ditto for Dovecot, but that's a different list.




On 5/9/17 7:20 AM, John wrote:
I am trying to debug a problem with my mail system. I think the 
problem is with Dovecot, or Thunderbird.


However, just to make sure i am not missing something really stupid 
could I get a check on my postfix setup.


TIA

John A

OT? - Blocking attachments

[john]

This may not be a Postfix problem, but bearing in mind the recent events 
this forum may have some good ideas.


After the recent rasomeware attacks we are considering the idea of 
blocking all attachments.  I am not sure of the best way of doing this, 
but several ideas have been put forward:


1. block all email with attachments - a little too drastic for some as
   there are legit reasons for attachments.
   block all email that is in any format that can hide executable code.
2. rename attachments so that they will not/cannot be executed/run by
   just opening them.
3. only allow email with attachments from a preauthorized list of
   senders. I am not sure that this would be effective as sender
   addresses are (i believe) easily spoofed.
4. email with attachments are diverted to a recipient for examination.
   If cleared they could then be forwarded to the original addressee.
   At lot of work for someone.
5. a variation on 2. sender has to asks the recipient for permission to
   send attachment. Recipient then adds sender to list, recipient will
   be automagically removed from list after a period of time.


I am not keen on any of these. But as I have to come up with a 
recommendation I think I would go with 1. If you want to send us 
something then put it in "drop box" and tell us about it. My second 
choice would be 5 + 2.


Another idea is to attachments are diverted and held for a period. After 
which they would be automatically be sent on as "normal". If there is 
something going on then the automatic forwarding would be suspended.


Are any of these do-able and if so where can I find suggestions on how 
to implement.


JohnA

smtp_tls-security_level .may/dane/encrypt

[John]

I currently use "smtp_tls_security_level = dane"  but recent discussion 
have made me wonder if I should change that. Maybe encrypt.


john A



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
smtp   inet  n   -   n   -   1   postscreen
smtpd  pass  -   -   n   -   -   smtpd
-o cleanup_service_name=pre-cleanup
pickup fifo  n   -   n   60  1   pickup
-o cleanup_service_name=pre-cleanup
submission inet  n   -   n   -   30  smtpd
-o content_filter=smtp-amavis:[127.0.0.1]:10026
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/dovecot-auth
-o smtpd_sasl_local_domain=$mydomain
-o broken_sasl_auth_clients=yes
-o smtpd_sasl_authenticated_header=yes
-o smtpd_client_restrictions=
-o smtpd_data_restrictions=
-o smtpd_etrn_restrictions=reject
-o smtpd_helo_restrictions=
-o {smtpd_recipient_restrictions=check_sender_access 
hash:/etc/postfix/maps/submission_access, reject}
-o smtpd_relay_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_client_connection_count_limit=15
-o smtpd_client_connection_rate_limit=80
-o smtpd_delay_reject=yes
-o cleanup_service_name=pre-cleanup
qmgr   fifo  n   -   n   300 1   qmgr
tlsmgr unix  -   -   n   1000?   1   tlsmgr
rewriteunix  -   -   n   -   -   trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   n   -   -   smtp
-o smtp_sasl_auth_enable=no
-o smtp_bind_address=74.116.186.178
-o smtp_bind_address6=2606:6d00:100:4301::1:200
relay  unix  -   -   n   -   -   smtp
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discardunix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache
smtp-amavis unix -   -   n   -   4   smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o smtp_tls_note_starttls_offer=no
127.0.0.1:10025 inet n   -   n   -   -   smtpd
-o content_filter=
-o mynetworks=127.0.0.0/8
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=permit_mynetworks,reject
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o local_header_rewrite_clients=
-o local_recipient_maps=
-o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
-o smtpd_tls_security_level=none
-o local_recipient_maps=
-o relay_recipient_maps=
pre-cleanup unix n   -   n   -   0   cleanup
-o virtual_alias_maps=
cleanupunix  n   -   n   -   0   cleanup
-o mime_header_checks=
-o nested_header_checks=
-o header_checks=
-o body_checks=
dnsblogunix  -   -   n   -   0   dnsblog
tlsproxy   unix  -   -   n   -   0   tlsproxy
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_size_limit = 65536
compatibility_level = 2
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 20
delay_warning_time = 12h
disable_vrfy_command = yes
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix/html
inet_protocols = all
mailbox_transport = lmtp:unix:private/dovecot-lmtp
message_size_limit = 32768000
mime_header_checks = pcre:/etc/postfix/maps/mime_header_checks.pcre
mydestination = localhost, localhost.localdomain, localdomain
mydomain

Re: smtp_tls-security_level .may/dane/encrypt

[John]

Thanks Viktor.

I try not to mess with my configuration too much, working on the 
principal is it ain't broke don't fix it.


John A


On 5/26/17 9:44 PM, Viktor Dukhovni wrote:

On May 26, 2017, at 9:40 PM, John  wrote:

I currently use "smtp_tls_security_level = dane"  but recent discussion have 
made me wonder if I should change that. Maybe encrypt.

These address entirely different use-cases.  So no.

Use "encrypt" when all mail goes to a single relayhost with no way
to authenticate that relayhost.

Use "dane" when delivering "direct to MX", that is, wherever the
MX records of various domains might point.




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[John]

You might find this useful 
https://github.com/zzz2002/Certbot_TLSAgen_Hook I wrote it to address a 
similar problem.


if there is a problem with it let me know and I will try to fix it.  i 
had intended to add other update mechanisms, but i have not had time to 
get working on them.


John A


On 6/30/2017 8:06 PM, /dev/rob0 wrote:

On Wed, Apr 20, 2016 at 01:19:29PM -0500, I wrote:

On Wed, Apr 20, 2016 at 03:53:24PM +, Viktor Dukhovni wrote:

[ LE certificate expired, DANE notification received ]


My temporary fix was to remove the TLSA records, sorry.  I cannot
risk losing mail as my poor brain tries to digest all this. :)

14 months later I got back to this. :)


I'm going to consider my options here before I replace the TLSA
records.  I am thinking I only want my LE cert on submission (so
that MUAs will be able to verify it) and to replace my port 25 cert
with one from my own private CA.

And this is what I have done, initially on domain nodns4.us, but
several other zones are signed and will be using TLSA records.

Thanks again for all your work on DANE and Postfix.

Thanks also to P@rick and the sys4.de gang for the validation site.

Question: I noticed my domain in a drop-down list there.  Is the
validation site maintaining a list of DANE-enabled and former DANE
zones?  IOW, should I drop a note to Victor when adding more zones,
or is the validation site taking care of that?



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

removing postgrey - reconfigring postix

[john]

I have been using postgrey for some time, but recently I have seen some 
posting that indicate that this is not the "best" way of spam control.


Is there a write up of how to setup up postscreen for maximum spam control.

TIA

John A

Re: removing postgrey - reconfigring postix

[john]

On 2018-01-24 07:15 PM, Peter wrote:

On 24/01/18 19:32, john wrote:

Is there a write up of how to setup up postscreen for maximum spam control.

Of course there's the official docs, POSTSCREEN_README and
postscreen(8).  I also recommend this:

http://rob0.nodns4.us/postscreen.html


Peter


 * Sorry for the delay in replying.
 * I had been using postgrey, but a recent article indicated that this
   delayed mail unnecessarily and postscreen might do a better job. I
   had been looking for something that gave me more than a recipe for
   postscreen. A "tutorial" on postscreen?
 * thanks for the link

John A

Re: removing postgrey - reconfigring postix

[john]

On 2018-01-24 07:15 PM, Peter wrote:

On 24/01/18 19:32, john wrote:

Is there a write up of how to setup up postscreen for maximum spam control.

Of course there's the official docs, POSTSCREEN_README and
postscreen(8).  I also recommend this:

http://rob0.nodns4.us/postscreen.html


Peter


 * Sorry for the delay in replying.
 * I had been using postgrey, but a recent article indicated that this
   delayed mail unnecessarily and postscreen might do a better job. I
   had been looking for something that gave me more than a recipe for
   postscreen. A "tutorial" on postscreen?
 * thanks for the link

John A

Re: aquamail connecting to postfix

[John]

I have AquaMail working on a S7edge running Lineageos 14.1 (have had it 
working on vanilla samsung touchwiz). My setting are:


 * imap
 o server: imap.klam.ca
 o security type - SSL (strict check)
 o server port: 993
 o authentication:chose automatically
 o login: x
 o password:
 o folder prefix: automatic

 * smtp
 o security type: Starttls(strict check)
 o server port: 587
 o authentication: choose automatically
 o login:
 o password:

this works for me

best of luck

john a


On 2018-02-11 06:12 PM, David Mehler wrote:

Hello,

Does anyone have Android's aquamail app successfully connecting to a
Postfix server? If so, w hat settings did you use? I keep getting an
authentication denied error. I've tried for authentication choose
automatically, sasl plain, sasl login. For server security I've tried
ssl strict check, ssl accept any (both on port 465), and starttls
strict check and starttls accept any (port 587).

Thanks.
Dave.

Re: aquamail connecting to postfix

[john]

Hi dav,

My internet was down overnight, snow plough hit encapsulation point.

These are my postfix config files, plus my dovecot stuff.

Hope it helps.

John A



On 2018-02-11 06:12 PM, David Mehler wrote:

Hello,

Does anyone have Android's aquamail app successfully connecting to a
Postfix server? If so, w hat settings did you use? I keep getting an
authentication denied error. I've tried for authentication choose
automatically, sasl plain, sasl login. For server security I've tried
ssl strict check, ssl accept any (both on port 465), and starttls
strict check and starttls accept any (port 587).

Thanks.
Dave.


alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_size_limit = 65536
compatibility_level = 2
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 20
delay_warning_time = 12h
disable_vrfy_command = yes
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix/html
inet_protocols = all
mailbox_transport = lmtp:unix:private/dovecot-lmtp
message_size_limit = 32768000
mime_header_checks = pcre:/etc/postfix/maps/mime_header_checks.pcre
mydestination = localhost, localhost.localdomain, localdomain
mydomain = klam.ca
myhostname = smtp.$mydomain
mynetworks = 127.0.0.0/8, [::1]/128
myorigin = $mydomain
postscreen_access_list = permit_mynetworks
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = drop
postscreen_disable_vrfy_command = $disable_vrfy_command
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2 
bl.spameatingmonkey.net*2 bl.ipv6.spameatingmonkey.net*2 bl.spamcop.net 
dnsbl.sorbs.net psbl.surriel.com bl.mailspike.net swl.spamhaus.org*-4 
list.dnswl.org=127.[0..255].[0..255].0*-2 
list.dnswl.org=127.[0..255].[0..255].1*-3 
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_whitelist_threshold = -1
postscreen_enforce_tls = $smtpd_enforce_tls
postscreen_greet_action = enforce
postscreen_helo_required = yes
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes
postscreen_use_tls = $smtpd_use_tls
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relocated_maps = hash:/etc/postfix/maps/relocated
smtp_dns_support_level = dnssec
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = DES, MD5, RC2, RC4, RC5, IDEA, SRP, PSK, aDSS, 
kECDhe, kECDhr, kDHd, kDHr, SEED, LOW, EXPORT
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions = reject_unknown_reverse_client_hostname, 
reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org, 
reject_rbl_client bl.spameatingmonkey.net, reject_rbl_client 
bl.ipv6.spameatingmonkey.net, reject_rbl_client bl.spamcop.net
smtpd_data_restrictions = reject_multi_recipient_bounce, 
reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_error_sleep_time = 1s
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname, 
reject_non_fqdn_helo_hostname, check_helo_access 
pcre:/etc/postfix/maps/helo_checks.pcre
smtpd_recipient_limit = 128
smtpd_recipient_restrictions = reject_non_fqdn_recipient, 
reject_unknown_recipient_domain, check_recipient_access 
pcre:/etc/postfix/maps/recipient_checks.pcre, check_recipient_access 
hash:/etc/postfix/maps/recipient_checks
smtpd_relay_restrictions = reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_sender_restrictions = reject_non_fqdn_sender, 
reject_unknown_sender_domain, check_sender_access 
hash:/etc/postfix/maps/sender_checks
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.klam.ca/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = auto
smtpd_tls_exclude_ciphers = $smtp_tls_exclude_ciphers
smtpd_tls_key_file = /etc/letsencrypt/live/mail.klam.ca/privkey.pem
smtpd_tls_mandatory_protocols = $smtp_tls_mandatory_protocols
smtpd_tls_protocols = $smtp_tls_protocols
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/maps/transport
virtual_alias_maps = proxy:pgsql:/etc/postfix/sql/virtual_alias_map.sql, 
proxy:pgsql:/etc/postfix/sql/virtual_alias_domain_map.sql
virtual_mailbox_domains = proxy:pgsql:/etc/postfix/sql/virtual_domain_map.sql
virtual_mailbox_maps = proxy:pgsql:/etc/postfix/sql/virtual_mailbox_map.sql, 
proxy:pgsql:/etc/postfix/sql/virtual_alias_domain_mailbox_map.sql
virtual_transport = lmtp:unix:private/dovecot-lmtp
smtp   inet  n   -   n   -   1   postscreen
smtpd  pass  -   -   n   -   -   smtpd -o 
cleanup_service_name=pre-cleanup
pickup fifo  n   -   n   60  1   pickup -o 
cleanup_service_name=pre-cleanup
submission inet  n   -   n   -   30  smtpd -o 
cont

Greylisting?

[john]

I  was just taking a look through my postfix configuration and noticed 
that I have a "check_policy_service" for postgrey a greylisting service.


I greylisting still considered worthwhile or should I drop it?

TIA

John A

Re: Greylisting?

[john]

Thanks.


On 2018-03-11 10:39 PM, john wrote:
I  was just taking a look through my postfix configuration and noticed 
that I have a "check_policy_service" for postgrey a greylisting service.


I greylisting still considered worthwhile or should I drop it?

TIA

John A

Re: question about envelop from.

[John]

Too complicated? How could this be improved?

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = DES, MD5, RC2, RC4, RC5, IDEA, SRP, PSK, 
aDSS, kECDhe, kECDhr, kDHd, kDHr, SEED, LOW, EXPORT

smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, high
smtp_tls_protocols = !SSLv2, !SSLv3

smtpd_sasl_auth_enable = no

smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = auto
smtpd_tls_exclude_ciphers = $smtp_tls_exclude_ciphers
smtpd_tls_protocols = $smtp_tls_protocols
smtpd_tls_mandatory_protocols = $smtp_tls_mandatory_protocols

Re: question about envelop from.

[john]

Thanks for the help.



smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, high

Where did you get the idea that "high" was a TLS protocol version?


I think this got in there by mistake, its not in my postfiix 
configuration. My guess is that I started typing before moving cursor. 
ooops!

Sorry.

John A

Re: rewrite/masquerade configuration

[john]

I'm in the process of making your suggested changes and testing. But not sure
how these changes will address the two users I need to stay local. 


John



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: Mail server without MX record

[john]

Someone mentioned earlier that the OP (Jason Long) might be a bot.  
While I personally don't think this is the case, I do think we might be 
getting trolled...


A quick Google search shows that this same username\email is on several 
different sites recently asking similar questions for a variety of 
products.


Just my .02...

https://www.google.com/search?q=jason+long+hack3rcon

Re: Deprecated: white is better than black

[john]

I've purposefully held off on responding to any of this but if the 
devs\list-owners are fine with the community converting this into a 
forum about race + software & computer terms, albeit temporarily, then 
fine - let's "damn the torpedos & full steam ahead" this baby and get to 
work...


We all ready?


On 2021-02-24 16:57, Emmett Culley wrote:

On 2/24/21 12:40 PM, Dirk Stöcker wrote:

On Wed, 24 Feb 2021, Wietse Venema wrote:


Postfix version 3.6 deprecates terminology that implies white is
better than black. Instead, Postfix prefers 'allowlist', 'denylist',
and variations on those words.


We had a late start, but it seems Newspeak will be established until 
2050 as originally intended by ministery of truth.


Doubleplusgood!

Ciao

What it the problem people seem to have with honest attempts to
address systemic racism in the world and the US especially.  We can
expect NOTHING to change if we take a "I couldn't be bothered"
attitude.

I can only assume that if you are complaining about someone else's
attempt to begin taking action, then you are a racist.  If not, then I
apologize.  But only if you are not.

Yes, it took some effort to make these recent changes, and All I can
say is thank you for doing that!

Emmett

Re: Deprecated: white is better than black

[john]

"Let's not do that."

I would wholeheartedly agree...and that was actually my point.

I view this forum as being a place for all things Postfix but only 
Postfix - not the possible root-cause nor philosophies behind why 
nomenclature might be the way it is.


None of us enjoys a universal right to free expression on this mailer - 
that is determined by Wietse.  And IIRC, last June, Weitse did open this 
mailer up to more race-related discussion re: Postfix nomenclature but 
that discussion is over, the changes have been made, and IMO, any 
further race related discussion here is inappropriate...



On 2021-02-24 17:29, Wietse Venema wrote:

j...@nunyuh.net:

I've purposefully held off on responding to any of this but if the
devs\list-owners are fine with the community converting this into a
forum about race + software & computer terms, albeit temporarily, then
fine - let's "damn the torpedos & full steam ahead" this baby and get 
to

work...

We all ready?


Let's not do that. I have merely done away with the implication
that white (as in whitelist) is better than black (as in blacklist).
It is not the end of the world. No-one will be forced to give up
their life style. The change is configurable, backwards-compatible
by default.

Wietse

building postfix 2.7 from source

[john]

Background, I am using Centos as a base distro, though I seem to be 
getting further and further away from the original install as its seems 
to be somewhat/very out of date.
I am not very keen on debian/ubuntu for the server as the developers 
there make IMHO "odd" changes to other peoples software, rather than 
passing and ideas/patches back to the original developers.
I kept on running into problems relating their package to the original 
package/documentation.


I installed Simon Mudd's postfix 2.7 build, however it is missing some 
important bits as far as I am concerned, support for Dovecot, sasl, 
pcre, tls, and (needed down the road) ldap.


So, taking my courage in both hands I am about to build my own binaries/rpm.

I assume that the source rpm on the postfix site has all the needed patches.

Any advice for someone about to venture into VERY unfamiliar waters. ( a 
good tutorial wold be good).


JohnA

building Postfix 2.7 from source Help!

[john]

i am attempting to build Postfix from the source rpms, I think I have 
worked out how to set the various parameters to get the options I want.

except I don't see how to make this a x86_64 install.
What am i missing?
JLA

Re: building Postfix 2.7 from source Help!

[john]

On 12/04/2010 2:20 AM, ram wrote:


On Sun, 2010-04-11 at 19:51 -0400, john wrote:

i am attempting to build Postfix from the source rpms, I think I have
worked out how to set the various parameters to get the options I want.
except I don't see how to make this a x86_64 install.
What am i missing?
JLA

 



On a redhat like  box this should work
rpmbuild --rebuild /path/postfix.xxx.src.rpm



Thanks, so nothing special to get a 64 bit (x86_64) version.
Now all I have to work out is how to get the options I want, There I 
think I am making progress, time will  tell.

Once again thanks
JLA

Connection Refused when sending on from local domain

[John]

 Hi,

We have a Postfix (2.7.1) instance running successfully for all of our 
mail needs, short of one scenario.  On our network, we are trying to 
configure other hosts (on the same class of private IP address - 
192.168.x.x) to forward mail (logwatch files) to an aliased user using a 
sendmail client.


Here is a snippet of a log entry, from the client, that shows the 
connection refused error:


Aug 11 20:15:41 myhost sendmail[17048]: o7B9uJjQ015169: 
to=, ctladdr= (0/0), 
delay=15:19:22, xdelay=00:00:00, mailer=esmtp, pri=1560372, 
relay=mail.example.com., dsn=4.0.0, stat=Deferred: Connection refused by 
mail.example.com.


In reading the documentation the only thing I could find that would 
affect this connection was $mydomain and $mynetworks, or so I assumed, 
but cannot seem to find the right "mixture" to be successful.  I've 
spent a considerable amount of time on this and am now asking what am I 
missing or what do I have misconfigured in order to get this work correctly?


Thanks for any help or pointing me in the right direction.

John

Here is the output of postconf -n

# postconf -n
alias_maps = hash:/etc/postfix/aliases
broken_sasl_auth_clients = yes
canonical_maps = pgsql:/etc/postfix/sql/pgsql-canonical-maps.cf
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
html_directory = no
inet_interfaces = $myhostname, localhost
mail_owner = postfix
mailbox_delivery_lock = fcntl, dotlock
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
masquerade_domains = $mydomain
message_size_limit = 2048
mydestination = $myhostname, mail.$mydomain
mydomain = example.com
myhostname = mail.example.com
mynetworks = 192.168.0.0/24, 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_tls_note_starttls_offer = yes
smtpd_helo_required = yes
smtpd_recipient_restrictions = 
permit_sasl_authenticated,permit_mynetworks,reject_non_fqdn_recipient,reject_non_fqdn_sender,reject_unauth_destination,reject_unknown_sender_domain,reject_rbl_client 
zen.spamhaus.org

smtpd_reject_unlisted_sender = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = check_sender_access 
hash:/etc/postfix/sender_access_map

smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/myhost.com-cert.pem
smtpd_tls_key_file = /etc/postfix/ssl/myhost.com-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
soft_bounce = no
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps = pgsql:/etc/postfix/sql/pgsql-virtual-alias-maps.cf
virtual_gid_maps = pgsql:/etc/postfix/sql/pgsql-virtual-gid-maps.cf
virtual_mailbox_base = /mail
virtual_mailbox_domains = 
pgsql:/etc/postfix/sql/pgsql-virtual-mailbox-domains.cf

virtual_mailbox_lock = fcntl, dotlock
virtual_mailbox_maps = 
pgsql:/etc/postfix/sql/pgsql-virtual-mailbox-recipients.cf

virtual_uid_maps = pgsql:/etc/postfix/sql/pgsql-virtual-uid-maps.cf

P.S. Thanks Ralph and Patrick for "The Book of Postfix", you'll likely 
recognize your virtual hosting solution from Chapter 14...

Re: OT: How to resolve big ISP mail drop

[john]

If, and its a big if, they are respecting the various RFCs that cover 
email then email to postmaster or abuse should get through. But as it is 
a big IF>


On 11/02/2011 12:15 PM, Gary Smith wrote:

Anyway, the question is, how does the community as a whole deal with
  big ISP's losing email? It seems that some companies (like ATT) seem
  to have less and less access to tools necessary for communicating with
  them on things like this. Is there any know lists of contact/support
  channels out there that people use for the larger ISP's?

As already stated, there's not a huge amount that you can do on your
own. However, if you're prepared to part with a bit of cash, then you
could look into using a whitelisting agent such as SuretyMail or
ReturnPath.

Andy,

Problem isn't white/grey/black listings, its that they accepted the email with 
a valid return code but it never made it to the destination box. It only seems 
to be happened on a few recipients. Basically, in short, the destination ISP 
(in this case ATT) is making some type of decision as to what email you are 
receiving. Buying additional technology won't exactly solve this problem.



--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Multi-homed server & inet_interfaces or smtp-bind-address

[John]

First off I am still a bit green on this stuff.

Both my servers are multi-homed, server A which runs Postfix is 
configured  ->  eth0 :n.n.n.186 and eth1:n.n.n.187.

The host name for this server is mail.domain.tld which points to n.n.n.187.

Up until last Friday we did not have any problems. On Friday we started 
to get bounced when we tried to reply to a new contact at AT&T/Prodigy.  
Their bounce message is as follows:
"host sbcmx5.prodigy.net[207.115.21.24] said: 553 5.3.0 flpd241 
DNSBL:ATTRBL 521< n.n.n.186 
>_is_blocked.__For_information_see_http://att.net/blocks (in reply to 
MAIL FROM command".
A check of our logs shows only four message destined for their servers 
in the last four weeks. I have check our servers using abuse.net and we 
do not appear to be an open relay. None of the RBL have us listed. So I 
do not think the problem is spamming.


I think the problem is Postfix is sending using eth0, which in turn 
means that it appears to come from n.n.n.186, which in turn means that a 
reverse lookup does not resolve to mail.domain.tld. The loop is not 
closed and therefor we are suspect.


I did some digging around I think that I need to modify my Postfix 
configuration by adding "inet_interfaces=n.n.n.186, n.n.n.187, 
localhost" and "smtp_bind_address=n.n.n.187". However this is where I 
get a little confused as in one set of documents I have read it says to 
add these into main.cf, while the postconf.5html say to leave the 
inet_interface at default and add the smtp_bind_address the master.cf.


Help would be appreciated, also any suggestions on improving the setup.
John A

postconf ouput below==

alias_database = $alias_maps
alias_maps = hash:/etc/aliases
allow_untrusted_routing = no
biff = no
body_checks = regexp:/etc/postfix/maps/body_checks
bounce_size_limit = 65536
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
debug_peer_level = 2
default_privs = nobody
default_process_limit = 20
delay_warning_time = 12
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/maps/header_checks
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = no
in_flow_delay = 1s
inet_protocols = all
local_destination_concurrency_limit = 5
mail_owner = postfix
mailbox_command = /usr/libexec/dovecot/deliver
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 32768000
mydestination = localhost, localhost.localdomain, localdomain
mydomain = domain.tld
myhostname = mail.$mydomain
mynetworks = 127.0.0.0/8, 192.168.40.0/28 n.n.n.176/28
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.5.5/README_FILES
recipient_delimiter = +
relay_domains =
relocated_maps = hash:/etc/postfix/maps/relocated
sample_directory = /usr/share/doc/postfix-2.5.5/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_CAfile = /etc/pki/CA/sub.class2.server.ca.crt
smtp_tls_cert_file = /etc/pki/tls/certs/Linderly_Mail_SSL.crt
smtp_tls_key_file = /etc/pki/tls/private/Linderly_Mail_SSL_Decrypted.key
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP
smtpd_data_restrictions = reject_multi_recipient_bounce, 
reject_unauth_pipelining, permit
smtpd_delay_reject = yes
smtpd_error_sleep_time = 5s
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_recipient_limit = 128
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unauth_destination,
reject_unlisted_recipient,
check_sender_access hash:/etc/postfix/maps/sender_access,
reject_unlisted_sender,
check_client_access hash:/etc/postfix/maps/client_access,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
check_helo_access pcre:/etc/postfix/maps/helo_checks,
check_helo_access pcre:/etc/postfix/maps/helo_access,
reject_unknown_helo_hostname,
check_recipient_access hash:/etc/postfix/maps/recipient_access  
reject_unknown_sender_domain,
check_policy_service unix:/var/spool/postfix/postgrey/socket
permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_soft_error_limit = 10
smtpd_tls_CAfile = /etc/pki/CA/sub.class2.server.ca.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/pki/tls/certs/Linderly_Mail_SSL.crt
smtpd_tls_key_file = /etc/pki/tls/private/Linderly_Mail_SSL_Decrypted.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = no
strict_rfc821_e

Re: Multi-homed server & inet_interfaces or smtp-bind-address

[John]

On 2/15/2011 7:07 PM, Jeroen Geilman wrote:

On 02/15/2011 08:21 PM, John wrote:

First off I am still a bit green on this stuff.

Both my servers are multi-homed, server A which runs Postfix is 
configured  ->  eth0 :n.n.n.186 and eth1:n.n.n.187.
The host name for this server is mail.domain.tld which points to 
n.n.n.187.


Up until last Friday we did not have any problems. On Friday we 
started to get bounced when we tried to reply to a new contact at 
AT&T/Prodigy.  Their bounce message is as follows:
"host sbcmx5.prodigy.net[207.115.21.24] said: 553 5.3.0 flpd241 
DNSBL:ATTRBL 521< n.n.n.186 
>_is_blocked.__For_information_see_http://att.net/blocks (in reply to 
MAIL FROM command".
A check of our logs shows only four message destined for their 
servers in the last four weeks. I have check our servers using 
abuse.net and we do not appear to be an open relay. None of the RBL 
have us listed. So I do not think the problem is spamming.


I think the problem is Postfix is sending using eth0, which in turn 
means that it appears to come from n.n.n.186, which in turn means 
that a reverse lookup does not resolve to mail.domain.tld. The loop 
is not closed and therefor we are suspect.


I did some digging around I think that I need to modify my Postfix 
configuration by adding "inet_interfaces=n.n.n.186, n.n.n.187, 
localhost" and "smtp_bind_address=n.n.n.187". However this is where I 
get a little confused as in one set of documents I have read it says 
to add these into main.cf, while the postconf.5html say to leave the 
inet_interface at default and add the smtp_bind_address the master.cf.


inet_interfaces defines which IPs (and ergo interfaces) postfix 
RECEIVES mail on.
This can be overridden per-service by providing the desired IP in the 
master.cf service definition.


smtp_bind_address defines which IP postfix uses to SEND mail.
This can be overridden for any outgoing smtp(8) transport.

Unsurprisingly, postconf(5) is correct.
I did not say the postconf(5) is wrong just I had received conflicting 
info on how and where to use smtp_bind_address.
Thanks for the clarification above, perhaps if it had been included in 
the postconf docs I might not have had the ?.
I decided I would try the "suck it and see" approach and added it to the 
master.cf as this seemed from the documentation to be the /best/ place 
to put it. I have to say it did not solve the problem with AT&T, but I 
can now see that when I send email I appear to be using the correct IP 
address, which would seem to be an improvement.


Thanks
John A

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: Multi-homed server & inet_interfaces or smtp-bind-address - solved sort of.

[John]

[snip]

I think the problem is Postfix is sending using eth0, which in turn
means that it appears to come from n.n.n.186, which in turn means that a
reverse lookup does not resolve to mail.domain.tld. The loop is not
closed and therefor we are suspect.

then why not fix that?

I would like to, unfortunately I cannot do this at the moment some 
custom client software uses fixed IP addresses rather than doing the 
right thing and using DNS. fortunately we have decided to drop it in 3 - 
6 months.

n.n.n.186   PTR foo.example.com
n.n.n.187   PTR bar.example.com

foo.example.com A n.n.n.186
bar.example.com A n.n.n.187

if that's not possible, then maybe

n.n.n.186   PTR mail.example.com
n.n.n.187   PTR mail.example.com

mail.example.comA n.n.n.186
mail.example.comA n.n.n.187


[snip]

to define the IP used to send mail, use smtp_bind_address. however, if
you have mail that should go through another interface, then you'd
better define two smtp transports and configure each with its
smtp_bind_address (using -o), then setup transport entries to select
which smtp to use.
No, all mail goes through the one interface, so I added the 
smtp_bind_address to master.cf, and it seems to work like a charm.
It has not solved the problem with AT&T, but I am not sure what the real 
problem is. I have written to the Postmaster outlining the problem we 
are having, now I just have to wait for a reply. I am not holding my breath.

do not touch inet_interfaces unless you really need that. your example
(inet_interfaces=ip1 ip2 localhost) looks useless.
I thought so to.  I could not see the difference between the default 
value of all and the suggest value of  ip1 ip2 localhost, as a

far  as I could see the default value would be ip1 ip2 localhost.

Thanks for the input

John A

--

"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: How to configure postfix to reject every incoming mail with a temporary error?

[John]

On 2/20/2011 8:05 AM, Matthias Egger wrote:

Background:

After getting complaints about mails which could not be delieverd to 
us i checked the logfiles and found nothing. By nothing i really mean 
nothing. Postfix did not even log a "connect from".


So i started to snoop on the network and found out that incoming mails 
from one of their server does (SYN), we (SYN, ACK) they (ACK) and then 
Postfix sends his "220 smtp..." stuff. But when mails are coming from 
another server they (SYN), we (SYN, ACK), they (ACK) and then we again 
(SYN, ACK) (which after a few more (TCP Dup ACK) and (SYN, ACK) leads 
to a [RST, ACK]).


As our server team has recently patched the solaris machine postfix is 
running on, this behaviour could be a bug releated to this patching.


So my idea was to temporarely change the solaris postfix machine with 
my linux laptop, making sure it uses the same IP and MAC Address and 
some basically configured postfix, while using tcpdump to check if 
these connections behave like before.


My Question:
While i am snooping and waiting for connections from this particular 
server, other incoming mails should be rejected by this temporary 
postfix. But only in a "soft" reject manner. So is there a way to 
configure (or missconfigure?) postfix to tell every incoming attempt 
something like "Sorry, i have a temporary problem. Try to connect later".


Best regards,
Matthias
My understanding of your problem is that you think the TCP/IP stack is 
broken on your mail server and that you wish it defer all deliveries 
until you have investigated and fixed the stack problem if it exists. 
While this is going on you want to substitute a "dummy" smtp server 
(using a laptop) designed to request deferred delivery until the problem 
is fixed. You could just go offline, I am not sure that you need to do 
anything as most smtp servers will retry delivery for a considerable period.
However, if you feel that it would be better to defer then, I think all 
you need to do is setup a postfix server  with a minimal configuration 
and set the "smtp_client_restrictions = defer" should ensure that all 
email is deferred. It might be a good idea to change the "defer_code" to 
421 from 450.

Hope this helps
--

"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: How to configure postfix to reject every incoming mail with a temporary error?

[John]

On 2/21/2011 5:16 PM, Jeroen Geilman wrote:

On 02/21/2011 11:09 PM, John wrote:

On 2/20/2011 8:05 AM, Matthias Egger wrote:

Background:

After getting complaints about mails which could not be delieverd to 
us i checked the logfiles and found nothing. By nothing i really 
mean nothing. Postfix did not even log a "connect from".


So i started to snoop on the network and found out that incoming 
mails from one of their server does (SYN), we (SYN, ACK) they (ACK) 
and then Postfix sends his "220 smtp..." stuff. But when mails are 
coming from another server they (SYN), we (SYN, ACK), they (ACK) and 
then we again (SYN, ACK) (which after a few more (TCP Dup ACK) and 
(SYN, ACK) leads to a [RST, ACK]).


As our server team has recently patched the solaris machine postfix 
is running on, this behaviour could be a bug releated to this patching.


So my idea was to temporarely change the solaris postfix machine 
with my linux laptop, making sure it uses the same IP and MAC 
Address and some basically configured postfix, while using tcpdump 
to check if these connections behave like before.


My Question:
While i am snooping and waiting for connections from this particular 
server, other incoming mails should be rejected by this temporary 
postfix. But only in a "soft" reject manner. So is there a way to 
configure (or missconfigure?) postfix to tell every incoming attempt 
something like "Sorry, i have a temporary problem. Try to connect 
later".


Best regards,
Matthias
My understanding of your problem is that you think the TCP/IP stack 
is broken on your mail server and that you wish it defer all 
deliveries until you have investigated and fixed the stack problem if 
it exists. While this is going on you want to substitute a "dummy" 
smtp server (using a laptop) designed to request deferred delivery 
until the problem is fixed. You could just go offline, I am not sure 
that you need to do anything as most smtp servers will retry delivery 
for a considerable period.
However, if you feel that it would be better to defer then, I think 
all you need to do is setup a postfix server  with a minimal 
configuration and set the "smtp_client_restrictions = defer" should 
ensure that all email is deferred. It might be a good idea to change 
the "defer_code" to 421 from 450.

Hope this helps


ITYM smtpD_client_restrictions

Yep, you are right I screwed up. just for clarity 
"smtp_client_restrictions" should read "smtp*d*_client_restrictions".

Thanks Jeroen.

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: Starting postfix

[john]

The operative words are desktop computer, the problem it would seem to 
me, is that Upstart is being used in an environment for which it has not 
been designed and is trying to solve problems that do not occur on a server.

Perhaps we need to point this out to the good folks at Ubuntu etc.

jut my 2c worth
John A

[snip]
Since Upstart is new to me I decided to read about it: "[The 
shortcomings of sysvinit] leaves it unable to handle various tasks on 
a moderndesktop computer 
<http://en.wikipedia.org/wiki/Desktop_computer>elegantly, including: 
The addition or 

[snip]

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: Kernel Oops

[john]

What hardware are running openwrt on?

Re: Kernel Oops

[john]

On 04/03/2011 8:58 AM, Denis Shulyaka wrote:

Hi John,

It's D-Link DIR-825 router, CPU Atheros AR7161@680MHz (mips)

2011/3/4 john:

What hardware are running openwrt on?

I think that you are being a little ambitious, that box has 8M flash and 
64M RAM.


"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: Kernel Oops

[john]

I think you should listen to the advise you were given on the OpenWRT 
developers forum by Philip.



"All that is necessary for the triumph of evil is that good men do 
nothing." (Edmund Burke)

Re: minor typo in Postfix's change log

[John]

On 3/28/2011 8:59 AM, Lima Union wrote:

Hi, while looking in the change log for some info about an issue I'm
having[1] I found a simple typo in the date specified as shown here:

20200102

Workaround: don't report bogus Berkeley DB close errors as
fatal errors. All operations before close are already error
checked, so the data is known to be safe.  File: util/dict_db.c.

Didn't know to how to report this in another way (without 'spamming' the ML).
Regards.

[1] postfix/verify[3209]: close database
/var/lib/postfix/verify_cache.db: No such file or directory

I don't think that is the problem, "20200102" as a date seems a off?

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: expensive checks first

[John]

Is there something that shows the "expense" associated with each check.
I have looked through the documentation on the postfix site but could 
not find anything.


John A

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

postfix in a chroot jail

[john]

is there any good reason to run postfix chrooted?

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

OT: need some advice as to distro

[John]

Sorry to bring this here, but we are having trouble setting up a
Postfix/dovecot mail system.

Background:
We are a bunch of retirees, so cost is a factor in any decision. We all
have IT experience, some of going back decades, however the world of
Linux and its software is new to us all. We used the cook book approach
to setting up our first mail system. It uses Postfix/Dovecot on top of 
Fedora 8 and so far it works like a charm. While the cook-book approach
got up and running fairly easily I think we missed out on the learning
side of things.

However, there is a growing concern about the basic OS slipping too far
behind on important changes, the same goes for some of the packages we
are planning on using, so we have started looking at alternatives.

Fedora - a little too dynamic for use as a server. This is to be
expected as it is a development system which I don't think is aimed at a
production like environment, plus the latest release seems very desktop
oriented.
Centos 5.4 - while it looks like a good choice, there has been some
political infighting going on recently which makes us a little nervous
about its future. In addition we have found that a number of the core
packages we wish to use are out of date (postfix, dovecot, amavisd-new
among them).
Ubuntu 9.10 Server edition - I am not sure what to say here. While at
first glance it seems to be an ideal solution a, free server
distribution with a Canonical backing it up. However, the setup of some
packages seems to us "odd", overly complicated and arbitrary.
openSUSE - not tied, but some concerns over the Novel /Microsoft deal.

Thanks in advance
John A

OT: need some advice as to distro

[John]

Sorry to bring this here, but we are having trouble setting up a
Postfix/dovecot mail system.

Background:
We are a bunch of retirees, so cost is a factor in any decision. We all
have IT experience, some of going back decades, however the world of
Linux and its software is new to us all. We used the cook book approach
to setting up our first mail system. It uses Postfix/Dovecot on top of
Fedora 8 and so far it works like a charm. While the cook-book approach
got up and running fairly easily I think we missed out on the learning
side of things.

However, there is a growing concern about the basic OS slipping too far
behind on important changes, the same goes for some of the packages we
are planning on using, so we have started looking at alternatives.

Fedora - a little too dynamic for use as a server. This is to be
expected as it is a development system which I don't think is aimed at a
production like environment, plus the latest release seems very desktop
oriented.
Centos 5.4 - while it looks like a good choice, there has been some
political infighting going on recently which makes us a little nervous
about its future. In addition we have found that a number of the core
packages we wish to use are out of date (postfix, dovecot, amavisd-new
among them).
Ubuntu 9.10 Server edition - I am not sure what to say here. While at
first glance it seems to be an ideal solution a, free server
distribution with a Canonical backing it up. However, the setup of some
packages seems to us "odd", overly complicated and arbitrary.
openSUSE - not tied, but some concerns over the Novel /Microsoft deal.

Thanks in advance
John A

Re: OT: need some advice as to distro

[John]

Terry L. Inzauro wrote:
> John wrote:
>   
>> Sorry to bring this here, but we are having trouble setting up a
>> Postfix/dovecot mail system.
>>
>> Background:
>> We are a bunch of retirees, so cost is a factor in any decision. We all
>> have IT experience, some of going back decades, however the world of
>> Linux and its software is new to us all. We used the cook book approach
>> to setting up our first mail system. It uses Postfix/Dovecot on top of
>> Fedora 8 and so far it works like a charm. While the cook-book approach
>> got up and running fairly easily I think we missed out on the learning
>> side of things.
>>
>> However, there is a growing concern about the basic OS slipping too far
>> behind on important changes, the same goes for some of the packages we
>> are planning on using, so we have started looking at alternatives.
>>
>> Fedora - a little too dynamic for use as a server. This is to be
>> expected as it is a development system which I don't think is aimed at a
>> production like environment, plus the latest release seems very desktop
>> oriented.
>> Centos 5.4 - while it looks like a good choice, there has been some
>> political infighting going on recently which makes us a little nervous
>> about its future. In addition we have found that a number of the core
>> packages we wish to use are out of date (postfix, dovecot, amavisd-new
>> among them).
>> Ubuntu 9.10 Server edition - I am not sure what to say here. While at
>> first glance it seems to be an ideal solution a, free server
>> distribution with a Canonical backing it up. However, the setup of some
>> packages seems to us "odd", overly complicated and arbitrary.
>> openSUSE - not tied, but some concerns over the Novel /Microsoft deal.
>>
>> Thanks in advance
>> John A
>>
>> 
>
>
>
> Personally, Debian Stable (currently Lenny) is my Linux of choice for 
> production system. Package management via apt is second
> to none and everything is very well documented with a willing and able 
> community for support.
>
>
> Why restate whats already written:
> http://www.debian.org/intro/why_debian
>
>
> When it comes down to it, the best distro is the one "you" know how to use.  
> I would start with a distro that you are most
> comfortable with and know how to use the best.
>
>
> Good luck and kind regards,
>
>
> _Terry
>
>
>
>
>   
I took a quick look at Debian, but as it was very similar to Ubuntu
(which I know is based on Debian) it looked to have the same problems
from our perspective. An example, from the Postfix setup was the
replacement of the LMTP process binary with a symlink to the SMTP
binary. This may not be a real problem, perhaps the two binaries are the
same, and Debian/Ubuntu are being smart, but as I could not find a
rational for the change I have to wonder if this may be a problem in the
future.  Other examples are the strange reconfiguration of the Amavisd
config files, changes to SASL setup, all make us a little nervous.

Re: OT: need some advice as to distro

[John]

Thank you all for your input, having looked at the responses and
discussed amongst ourselves and as I am the grunt doing the work, we
will probably go with Centos.
Some of our reasoning was, it close to Fedora so we have some
experience, there are several third party repositories that carry the
"latest" packages and its fairly well documented.
That said, I think I will setup an Ubuntu server as an experiment just
to see how difficult/different it is in setup and operate.
Once again thank you all
John A

Re: OT: need some advice as to distro - Thank you all for the input.

[John]

We have decided to go with Centos as it is RedHat based and we hope
similar to Fedora.
At the same time I am going to start playing with a Ubuntu/Debian server
just to see how easy it is to get the config and results we want.

Once again thank you all for your input
John A

OT: need some advice as to disto - supplementary

[john]

I have setup up a Centos system to be used as a server by our group.
Because of our age etc., the question of how to administer the system, 
what tools are needed, what are available.
Part of the problem is that should the current admin have to be replaced 
it is exceedingly unlikely that they will be able to offer any guidance 
to their replacement or answer questions about the current setup about it.


1) how much administration does postfix actually need once its setup?
From what I have seen so far, with our previous Fedora Postfix setup 
and the new Centos one, that once the initial configuration is done 
Postfix requires very little tweaking or am I missing something?
We have thought of using a ldap service for the group address list and I 
think that could be used for various maps/list need by postfix which we 
think will reduce the maintenance effort. I am currently reading up on 
how to do this, pointers welcome.


2) Webmin and its addons, for postfix administration - good, bad or blah?

3) We currently have all our members configured as virtual users with 
all their email stored as maildir stores under /var/mail/example.com. We 
are considering giving each member a personal space, probably under 
/home (there would be no local login allowed. If we decide to go in this 
direction would it be a "good" idea to store the mail in a maildir under 
the individual user /home directory?


TIA
John A

smtp_sasl_auth_enable?

[john]

I understand that setting "smtp_sasl_auth_enable" to yes, enables sasl 
authentication in the SMTP client, but does it make it mandatory.
If I do not have an entry in the sasl password list for a particular 
smarthost/relay will I have a problem.

TIA
JLA

Where is postfix (qmgr) getting this wrong) transport from?

[John]

I am getting a warning message (see below) about an invalid connection 
to AmaVis-New.

My problem is that I cannot find where this connection is being defined.

system is Ubuntu 11.04
postfix 2.8.2-1ubuntu2.1
dovecot 1:1.2.15-3ubuntu2.1
amavis-new 1:2.6.5-0ubuntu2

what am I doing wrong? what am I missing? any other helpful suggestions.
TIA
John Allen

=== except from mail log ===
Aug 25 15:15:36 ls0 dovecot: imap-login: Login: 
user=, method=PLAIN, rip=74.82.82.252, 
lip=74.116.186.187, TLS
Aug 25 15:15:39 ls0 dovecot: IMAP(henry@linderly.com): Disconnected: 
Logged out bytes=125/8979
Aug 25 15:16:44 ls0 postfix/qmgr[3704]: 26A9B240091: 
from=, 
size=16135, nrcpt=1 (queue active)


*Aug 25 15:16:44 ls0 postfix/qmgr[3704]: warning: connect to transport 
private/smtp-amavis: No such file or directory*


Aug 25 15:16:44 ls0 postfix/qmgr[3704]: 0D3CE240094: 
from=, 
size=12218, nrcpt=1 (queue active)
Aug 25 15:16:44 ls0 postfix/qmgr[3704]: C1163240093: 
from=, 
size=26339, nrcpt=1 (queue active)
Aug 25 15:16:44 ls0 postfix/error[3831]: C1163240093: 
to=, relay=none, delay=8424, 
delays=8424/0.01/0/0.11, dsn=4.3.0, status=deferred (mail transport 
unavailable)


=== postconf -n output ===
alias_database = $alias_maps
alias_maps = hash:/etc/aliases
allow_untrusted_routing = no
biff = no
body_checks = regexp:/etc/postfix/maps/body_checks
bounce_size_limit = 65536
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
default_privs = nobody
default_process_limit = 20
delay_warning_time = 12
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/maps/header_checks
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix-2.7.0-documentation/html
inet_interfaces = all
inet_protocols = all
local_destination_concurrency_limit = 5
mail_owner = postfix
mailbox_command = /usr/lib/dovecot/deliver
mailbox_transport = dovecot
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 32768000
mydestination = localhost, localhost.localdomain, localdomain
mydomain = linderly.com
myhostname = mail.$mydomain
mynetworks = 127.0.0.0/8, 192.168.0.0/16, 74.116.186.176/28, [::1]/128, 
[2001:470:1f10:6bf::]/64

myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.7.0-documentation/readme
recipient_delimiter = +
relay_domains =
relocated_maps = hash:/etc/postfix/maps/relocated
sample_directory = /usr/share/doc/postfix-2.5.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_cert_file = /etc/ssl/certs/Linderly_Mail_SSL.crt
smtp_tls_enforce_peername = no
smtp_tls_key_file = /etc/ssl/private/Linderly_Mail_SSL.key
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP
smtpd_data_restrictions = reject_multi_recipient_bounce,
reject_unauth_pipelining,permit

smtpd_delay_reject = yes
smtpd_error_sleep_time = 5s
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_recipient_limit = 128
smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient,permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unlisted_recipient,reject_unlisted_sender,
check_client_access hash:/etc/postfix/maps/client_access,
reject_unknown_client_hostname,reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,check_helo_access 
pcre:/etc/postfix/maps/helo_checks,check_helo_access 
hash:/etc/postfix/maps/helo_access,check_recipient_access 
hash:/etc/postfix/maps/recipient_access,reject_rbl_client 
zen.spamhaus.org,reject_rbl_client bl.spamcop.net,
check_sender_access hash:/etc/postfix/maps/sender_access,
check_policy_service inet:127.0.0.1:10023permit

smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_soft_error_limit = 10
smtpd_tls_CAfile = /etc/ssl/certs/Linderly_CA_Class2.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/Linderly_Mail_SSL.crt
smtpd_tls_key_file = /etc/ssl/private/Linderly_Mail_SSL.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
soft_bounce = no
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
virtual_alias_maps = hash:/etc/postfix/maps/valiases
virtual_gid_maps = static:vmail
virtual_mailbox_base = /var/mail/vhosts

Where is postfix (qmgr) getting this wrong) transport from?

[John]

I am getting a warning message (see below) about an invalid connection 
to AmaVis-New.

My problem is that I cannot find where this connection is being defined.

system is Ubuntu 11.04
postfix 2.8.2-1ubuntu2.1
dovecot 1:1.2.15-3ubuntu2.1
amavis-new 1:2.6.5-0ubuntu2

what am I doing wrong? what am I missing? any other helpful suggestions.
TIA
John Allen

=== except from mail log ===
Aug 25 15:15:36 ls0 dovecot: imap-login: Login: 
user=, method=PLAIN, rip=74.82.82.252, 
lip=74.116.186.187, TLS
Aug 25 15:15:39 ls0 dovecot: IMAP(henry@linderly.com): Disconnected: 
Logged out bytes=125/8979
Aug 25 15:16:44 ls0 postfix/qmgr[3704]: 26A9B240091: 
from=, 
size=16135, nrcpt=1 (queue active)


*Aug 25 15:16:44 ls0 postfix/qmgr[3704]: warning: connect to transport 
private/smtp-amavis: No such file or directory*


Aug 25 15:16:44 ls0 postfix/qmgr[3704]: 0D3CE240094: 
from=, 
size=12218, nrcpt=1 (queue active)
Aug 25 15:16:44 ls0 postfix/qmgr[3704]: C1163240093: 
from=, 
size=26339, nrcpt=1 (queue active)
Aug 25 15:16:44 ls0 postfix/error[3831]: C1163240093: 
to=, relay=none, delay=8424, 
delays=8424/0.01/0/0.11, dsn=4.3.0, status=deferred (mail transport 
unavailable)


=== postconf -n output ===
alias_database = $alias_maps
alias_maps = hash:/etc/aliases
allow_untrusted_routing = no
biff = no
body_checks = regexp:/etc/postfix/maps/body_checks
bounce_size_limit = 65536
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
default_privs = nobody
default_process_limit = 20
delay_warning_time = 12
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/maps/header_checks
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix-2.7.0-documentation/html
inet_interfaces = all
inet_protocols = all
local_destination_concurrency_limit = 5
mail_owner = postfix
mailbox_command = /usr/lib/dovecot/deliver
mailbox_transport = dovecot
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 32768000
mydestination = localhost, localhost.localdomain, localdomain
mydomain = linderly.com
myhostname = mail.$mydomain
mynetworks = 127.0.0.0/8, 192.168.0.0/16, 74.116.186.176/28, [::1]/128, 
[2001:470:1f10:6bf::]/64

myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.7.0-documentation/readme
recipient_delimiter = +
relay_domains =
relocated_maps = hash:/etc/postfix/maps/relocated
sample_directory = /usr/share/doc/postfix-2.5.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_cert_file = /etc/ssl/certs/Linderly_Mail_SSL.crt
smtp_tls_enforce_peername = no
smtp_tls_key_file = /etc/ssl/private/Linderly_Mail_SSL.key
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP
smtpd_data_restrictions = reject_multi_recipient_bounce,
reject_unauth_pipelining,permit

smtpd_delay_reject = yes
smtpd_error_sleep_time = 5s
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_recipient_limit = 128
smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient,permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unlisted_recipient,reject_unlisted_sender,
check_client_access hash:/etc/postfix/maps/client_access,
reject_unknown_client_hostname,reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,check_helo_access 
pcre:/etc/postfix/maps/helo_checks,check_helo_access 
hash:/etc/postfix/maps/helo_access,check_recipient_access 
hash:/etc/postfix/maps/recipient_access,reject_rbl_client 
zen.spamhaus.org,reject_rbl_client bl.spamcop.net,
check_sender_access hash:/etc/postfix/maps/sender_access,
check_policy_service inet:127.0.0.1:10023permit

smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_soft_error_limit = 10
smtpd_tls_CAfile = /etc/ssl/certs/Linderly_CA_Class2.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/Linderly_Mail_SSL.crt
smtpd_tls_key_file = /etc/ssl/private/Linderly_Mail_SSL.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
soft_bounce = no
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
virtual_alias_maps = hash:/etc/postfix/maps/valiases
virtual_gid_maps = static:vmail
virtual_mailbox_base = /var/mail/vhosts

Re: Where is postfix (qmgr) getting this wrong) transport from?

[John]

Sorry, I screwed up some how when sending in my question.
John A

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: Where is postfix (qmgr) getting this wrong) transport from?

[John]

That fixed the problem.
Thank you!
John A

John:

*Aug 25 15:16:44 ls0 postfix/qmgr[3704]: warning: connect to transport
private/smtp-amavis: No such file or directory*

This means that your configuration specified content filter of
"smtp-amavis" at some earlier point in time.

If that is incorrect, you can move the message one more time through
the Postfix mail receiving daemons which should get rid of the
incorrect filter name.

This command:

# postsuper -r C1163240093

should do the job (assuming that you do content filter mail
submitted with the Postfix /usr/sbin/sendmail command).


Aug 25 15:16:44 ls0 postfix/error[3831]: C1163240093:
to=, relay=none, delay=8424,
delays=8424/0.01/0/0.11, dsn=4.3.0, status=deferred (mail transport
unavailable)

Wietse



--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Webmin as an admin tool?

[John]

I do not want to start a flam war, but what are the thoughts on using 
webmin as a tool to administer postfix (+ dovecot, but that is outside 
this group).

TIA
John Allen

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: Webmin as an admin tool?

[John]

My initial thought was to save my existing config, then use webmin to 
build a config and compare the two. if they are miles apart then drop 
the idea.
Part of my reasoning here is that I am getting old and I need to farm 
out some of my work, most of the people that I have been asked to look 
at are not CLI literate and are not particularly keen on becoming so.

TTYL
John Allen

John:

I do not want to start a flam war, but what are the thoughts on using
webmin as a tool to administer postfix (+ dovecot, but that is outside
this group).

The following is not specific to GUIs, but applies to any program
that automatically parses and updates configuration.  Be careful
about making changes by hand - the tool (GUI or otherwise) may not
understand everything.

Wietse



--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Header, body checks are they useful when using Amavis-new+Spamassassin?

[john]

I am running Ubuntu 11.04 as a SOHO server with 
postfix/dovecot/Amavis-new/Spamassassin/Clamav setup as my email service.


I currently use header and body checks in postfix as part of my 
anti-spam measures.

How useful and/or how effective are these measures?
Are they still worthwhile if I am using the 
Amavis-new/Spamassassin/Clamav setup for anti-spam?
The check files were originally from a third party (Jeff Posluns ?) and 
are fairly old, I have added some of my own checks but the basic files 
are originals. If these checks are still worthwhile are there more up to 
date files, and if so where might they be found?


TIA
John A

-- First they came for the Communists, but I was not a Communist so I 
did not speak out. Then they came for the Socialists and the Trade 
Unionists, but I was neither, so I did not speak out. Then they came for 
the Jews, but I was not a Jew so I did not speak out. And when they came 
for me, there was no one left to speak out for me. Dietrich Bonhoeffer - 
1906-1945

postfix config exemplar

[john]

Hi,
I am running Ubuntu 11.04 as a SOHO server with 
postfix/dovecot/Amavis-new/Spamassassin/Clamav setup as my email service.


I recently migrated from Centos 5.5 to Ubuntu 11.04. I order to get up 
and running ASAP I moved my old config from from one system making only 
those changes need to accommodate the differences in the distributions.
Is there a postfix setup which I could use to  check my config against 
in order to "tune" mine.


TIA
John A

--
First they came for the Communists, but I was not a Communist so I did not 
speak out.
Then they came for the Socialists and the Trade Unionists, but I was neither, 
so I did not speak out.
Then they came for the Jews, but I was not a Jew so I did not speak out.
And when they came for me, there was no one left to speak out for me.
Dietrich Bonhoeffer - 1906-1945

Off Topic: Auto-whitelisting from sent mail?

[john]

I think this is off topic.

I am running Ubuntu 11.04 as a SOHO server with 
postfix/dovecot/Amavis-new/Spamassassin/Clamav setup as my email service.


Does anybody know of a program... that can white list inbound email 
based upon the addresses of emails that have been sent?

I wondered if there was something that might work with Spamassassin et al?

TIA
John A

-- First they came for the Communists, but I was not a Communist so I 
did not speak out. Then they came for the Socialists and the Trade 
Unionists, but I was neither, so I did not speak out. Then they came for 
the Jews, but I was not a Jew so I did not speak out. And when they came 
for me, there was no one left to speak out for me. Dietrich Bonhoeffer - 
1906-1945

Re: Down To One Problem?

[john]

On 23/10/2011 2:33 PM, Simon Brereton wrote:

On 23 October 2011 13:13, Jack Fredrikson  wrote:

I may be dreaming, but this could be my last problem with my installation.
After following all your good advice, I still have this one problem and it
is pervasive in all emails:
Oct 23 09:50:58 myserver postfix/pipe[30578]: BB2BB5790262:
to=, relay=dovecot, delay=12684, delays=12683/0.18/0/0.27,
dsn=4.3.0, status=deferred (temporary failure. Command output: doveconf:
Warning: NOTE: You can get a new clean config file with: doveconf -n>
dovecot-new.conf doveconf: Warning: Obsolete setting in
/usr/local/etc/dovecot/dovecot.conf:5: imap_client_workarounds=outlook-idle
is no longer necessary doveconf: Warning: Obsolete setting in
/usr/local/etc/dovecot/dovecot.conf:17: add auth_ prefix to all settings
inside auth {} and remove the auth {} section completely doveconf: Warning:
Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:19: passdb pam {}
has been replaced by passdb { driver=pam } doveconf: Warning: Obsolete
setting in /usr/local/etc/dovecot/dovecot.conf:21: userdb passwd {} has been
replaced by userdb { driver=passwd } doveconf: Warning: Obsolete setting in
/usr/local/etc/dovecot/dovecot.conf:23: auth_user has been replaced by
service auth { user } dov

The strange thing about this is that googling "temporary failure. Command
output: doveconf: Warning: NOTE: You can get a new" brings up only
references to my post on this subject to the dovecot mailing list (which has
not responded)! That is, it appears nobody else has this problem! With
everyone else it's a matter of "Commad output: doveconf" throwing out some
error. So, what's the confounded problem?!

Probably best off asking on Dovecot about this one - but as I recall
you started with an ancient version of Dovecot.  So if you didn't get
rid of it completely you may well be using an old style config which
is causing the errors.

Open up your dovecot conf and have a look at these specific items...

Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:5:
imap_client_workarounds=outlook-idle is no longer necessary
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:17:
add auth_ prefix to all settings inside auth {} and remove the auth {}
section completely
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:19:
passdb pam {} has been replaced by passdb { driver=pam }
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:21:
userdb passwd {} has been replaced by userdb { driver=passwd }
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:23:
auth_user has been replaced by service auth { user } dov


My advice would be to do what it says and start with a new config.
Back up your old one for SQL specific stuff, run You can get a new
clean config file with: doveconf -n>>  dovecot-new.conf doveconf as
suggested and start from there.

Simon

As has been said this should probably be asked on Dovecot.
It looks to me as though you are using a Dovecot 1.x config on a Dovecot 
2.x install.
the dovecot - doveconf -n will output (suggested) 2.x config that can be 
used as a start.

Re: Down To One Problem?

[john]

Might I suggest you take a look here Dovecot 2.0 documentation - How to 
 which has several extremely good 
Dovecot How-tos. Of particular interest to you might be Virtual User 
Flat Files Postfix 
 which show 
how to setup Postfix + Dovecot  mail system, it includes a fairly 
comprehensive recipe covering both the Dovecot and Postfix configurations.

Re: Plesk or equivalent to manage Postfix ?

[john]

On 04/11/2011 2:26 PM, Patrick Ben Koetter wrote:

* Frank Bonnet:

On 11/04/2011 03:48 PM, /dev/rob0 wrote:

On Friday 04 November 2011 08:13:59 Frank Bonnet wrote:

Does anyone has ever use Plesk or another graphical interface
to manage Postfix ?

I'm sure they have.


If yes any infos/advices welcome

Don't. Such a GUI can only be as good as the GUI creator's
understanding of Postfix, and IME that does not seem to be very good.

If the actual problem you wish to address is to turn over control of
user management to non-technical persons, there are other choices.
Actual management of the MTA itself should never be turned over to
non-technical persons.

My problem is I MUST do this ( delegate minor tasks to a non
technical person )
of course I will install/configure the server myself for the first startup.
But some tasks such user's creation / destruction could be delegated

Modoboa is  a web based application to create, administrate, and use virtual
domain hosting platforms.

Modoboa stores its data in a SQL backend (like MySQL or PostgreSQL). Using
this database, you can integrate Modoboa with other mail components, such as
Postfix or Dovecot.

It is written in Python and uses the Django and Mootools frameworks.

And last but not least, Modoboa is open source and is licensed under the
MIT-license.
http://www.http://modoboa.org/

I tried installing Modoba on Ubuntu 11.04, in the end I gave up I just 
could not get it going. I am sure the problem is me, but IMO it is not 
for the faint hearted.

Email encryption check before accepting for transmission

[john]

We need to ensure that emails sent by some of our users are encrypted 
(medical records, reports, etc) before they are sent.


We only accept out going mail from our local users by submission (port 
587).


I realize that this is really the job of the MUA, but I would like to 
check that emails are in fact encrypted before being sent. If an 
unencrypted email is encountered transmission would be denied with a 
suitable message/code. One other thing that we might also need to do is 
to move the supplied subject into the body of the message and substitute 
a generic heading, this to prevent the patient name showing up in plain 
text.


I originally thought that the basic checking might be possible using 
header and/or body checks, but I am not sure if this will be reliable 
enough.


Is any of this possible, if so suggestions as to where to look or solutions.

John A

OT-follow up - postfix REGEX bug ???

[john]

Could somebody recommend a "good" tutorial on REGEX and/or PRCE?
John A

On 29/03/2012 11:35 AM, Женя wrote:

That's it. Ashamed.
Tricky REGEX. Thanks everyone. And thank you for great mail server.


:

  /google\.com/   OK
  /mail\.ru/ OK

You mean:

 /^google\.com$/
 /^mail\.ru$/

RTFM!

Wietse

Re: Running on idle systems

[john]

I do not see where Stan was abusive.
Abrasive maybe, but then sometimes bumps on logs need sanding down this 
would appear to be one of those occasions.


On 03/05/2012 11:29 AM, Stan Hoeppner wrote:

On 5/3/2012 8:48 AM, Michael Tokarev wrote:

On 03.05.2012 17:16, Stan Hoeppner wrote:
[]

To who at Debian?  Lamont Jones?  Has he replied to your idiotic idea yet?

Please refrain from using such words in public forum.
Such usage makes you to be of that kind.

My apologies for allowing my passion to transform into abrasiveness.


Thank you for making my worst nightmares come true. I will do
my best to prevent this from happening, and if I find out that
they do it anyway, then I will raise hell and it won't be pretty.

All of this nonsense because one guy on the planet feels he can't simply
use an MUA with submission like everyone else does, but demands he be
able to run an MTA on his damn desktop/laptop, and demands the default
MTA config allows him to do what he wants seamlessly, possibly to the
detriment of others, mainly the guy who wrote this MTA for your use in
the first place.  At least that's my read of this thread.

Your read is incorrect.  World is much larger than your imagination.

Please (re)explain the use case you have in mind.  It seemed to me the
changes you're proposing will have a positive effect, immediately
anyway, for only a very small subset of Postfix users, for a niche
configuration.

This request seems very similar to one made on the XFS list not all that
long ago.  A user with a home theater PC and a single large WD Green
drive was irked that the drive wouldn't stay asleep for more than 30
seconds.  He debugged it himself, and found a long standing XFS behavior
of accessing the journal or filesystem superblock every 30s IIRC.  He
said this wasn't necessary and pleaded with the devs to change this
behavior, just so his HTPC drive could sleep.  XFS was never intended
for such a setup, this behavior existing since ~1994/95.  The average
XFS setup is a server with a dozen to a few hundred or more drives in
hardware RAID running 24x7--no sleeping.  An SGI employee mentioned just
a couple of weeks ago working with a single XFS filesystem spaning 600
drives in an IS16000 array.  Not your average XFS drive count, but it is
a typical large XFS configuration, and quite a contrast from a single
drive HTPC server in a living room.

IIRC a patch was eventually developed after many months, when it was
determined there was likely no downside, and mainlined after much
regression testing and tweaking.  All for the benefit of very very few
non-typical XFS users.

Anyway, I see this as a similar case, and a similar waste of resources
expended for the benefit of very few users, when there is nothing
inherently "wrong" with the current Postfix implementation, as far as I
understand the request.  Maybe I simply don't fully understand the issue
and the potential benefits yet.

Re: separate log for amavisd-new

[john]

I am not sure that this is the right place to ask about NON-postfix 
problems.

But, have you checked the log file permissions.

JohnA
On 04/05/2012 12:45 PM, Scott Brown wrote:

Hello,
Instead of including the amavisd activity in the maillog, I want to have a 
separate log file.  I can't figure out how to get this working though.

For some reason, amavisd isn't writing to the log file that's defined in 
/etc/amavisd.conf

If I do a directory listing, the log still shows as 0 bytes:
ls -l amavis.log
-rwxrwxrwx 1 vscan vscan 0 Nov 30 09:39 amavis.log

when I initially set up the postfix/mysql/amavisd system, I created an empty 
amavis.log and changed the owner to the user amavis is running under:
chown vscan:vscan /var/log/amavis.log
chmod u=rw,g=rw,o=rw /var/log/amavis.log

Any idea what could be wrong?  Below are the relevant entries from amavisd.conf:
$log_level = 2;  # verbosity 0..5, -d
$log_recip_templ = undef;# disable by-recipient level-0 log entries
$DO_SYSLOG = 0;  # log via syslogd (preferred)
$LOGFILE = "/var/log/amavis.log";
$log_templ = '[? %#V |[? %#F |[?%#D|Not-Delivered|Passed]|BANNED name/type (%F)]|INFECTED 
(%V)], <%o> -> [<%R>|,][? %i ||, quarantine %i], Message-ID: %m, Hits: %c';
#$syslog_facility = 'local7';   # Syslog facility as a string
# e.g.: mail, daemon, user, local0, ... local7
#$syslog_priority = 'debug';  # Syslog base (minimal) priority as a string,
# choose from: emerg, alert, crit, err, warning, notice, info, debug


Thank you

Scott Brown

Re: my server generates spam

[john]

Off topic, but related to this thread.

I/we use Squirrelmail and while we have not had any problems with it I 
wonder (and as this is this list seems to be the home of email gurus) if 
there are any recommendations as to a better solution, particularly one 
that would work in a postfix/dovecote environment.


John A

On 10/05/2012 8:42 AM, Robert Schetterer wrote:

Am 10.05.2012 11:57, schrieb Giuseppe Perna:

perhaps using the webmail with this ip 176.61.140.133
BE80AB81E65: 
message-id=<62105.176.61.140.133.1336457923.squirrel@176.61.140.133>

your squirrelmail may get hacked by old version bugs and or php bugs
and using binary postfix sendmail for sending out
therefor it does not use some postfix smtp auth mech
for deliver out, you may never find some account in the webmail log
and if you might find , it will not be any help
also you stated before that you have no idea from smtp auth
stop the server, check your whole setup inkl webmail , update all
related software and linux distro,
read postfix docs, perhaps hire somebody near your for help
come back for questions then, after all done start the server again
thank you for using postfix

Re: my server generates spam

[john]

Sorry about the top post, but i wanted to give anybody who looked the 
earliest opportunity to skip as I was off topic.

Perhaps I should have started a new thread.

John A

mailbox_coomand

[john]

I recently "upgraded" my server to Debian 6.
One of the things that seems to have been changed in the Postfix-Dovecot 
setup is the configuration of the "mailbox_command".


In my old setup the command was

mailbox_command = /usr/lib/dovecot/dovecot-lda -f ${sender} *-d 
${recipient}* -m ${extension}


in the new setup the command is

mailbox_command = /usr/lib/dovecot/dovecot-lda -f ${sender} *-d 
${user}@${nexthop}* -m ${extension}


Similarly master.cf has also changed

dovecot   unix  -   n   n   -   -   pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f 
${sender} *-d ${recipient}* -m ${extension}


new setup

dovecot   unix  -   n   n   -   -   pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f 
${sender} *-d ${user}@${nexthop}* -m ${extension}



Which is better and why?

Re: mailbox_coomand

[john]

On 19/05/2012 8:46 AM, Jeroen Geilman wrote:

On 05/19/2012 04:01 AM, john wrote:

I recently "upgraded" my server to Debian 6.
One of the things that seems to have been changed in the 
Postfix-Dovecot setup is the configuration of the "mailbox_command".


In my old setup the command was

mailbox_command = /usr/lib/dovecot/dovecot-lda -f ${sender} *-d 
${recipient}* -m ${extension}


in the new setup the command is

mailbox_command = /usr/lib/dovecot/dovecot-lda -f ${sender} *-d 
${user}@${nexthop}* -m ${extension}


Similarly master.cf has also changed

dovecot   unix  -   n   n   -   -   pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f 
${sender} *-d ${recipient}* -m ${extension}


new setup

dovecot   unix  -   n   n   -   -   pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f 
${sender} *-d ${user}@${nexthop}* -m ${extension}



Which is better and why?



You'd have to consult the relevant *dovecot* documentation for 
questions relating to *dovecot*



Dovecot does not care what goes here, it just expects a string.

What I am trying to understand is the difference between the Postfix 
variable ${recipient} and ${user}@${nexthop}, and what are the 
advantages and/or disadvantages to either one?

Somebody thought it worth making the change, why?
Should I go with the "new and improved" or revert to my older but  
"tried and true"?


John A

Re: mailbox_coomand

[john]

On 19/05/2012 9:21 AM, mouss wrote:

Le 19/05/2012 04:01, john a écrit :

I recently "upgraded" my server to Debian 6.
One of the things that seems to have been changed in the Postfix-Dovecot
setup is the configuration of the "mailbox_command".

In my old setup the command was

mailbox_command = /usr/lib/dovecot/dovecot-lda -f ${sender} *-d
${recipient}* -m ${extension}

in the new setup the command is

mailbox_command = /usr/lib/dovecot/dovecot-lda -f ${sender} *-d
${user}@${nexthop}* -m ${extension}

Similarly master.cf has also changed

dovecot   unix  -   n   n   -   -   pipe
 flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f
${sender} *-d ${recipient}* -m ${extension}

new setup

dovecot   unix  -   n   n   -   -   pipe
 flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f
${sender} *-d ${user}@${nexthop}* -m ${extension}


Which is better and why?




For precise infos on the meaning and expansion of these variables, see
http://www.postfix.org/pipe.8.html

it really depends on your LDA and on what you want to achieve, but in
general, I'd say the order of pref is:

1- ${user}@${domain}  (but this is only available for postfix>= 2.5)
2- ${user}@${nexthop}
3- ${recipient}

to see why, think about delivering an address with an extension:
joe+extensi...@example.com (assuming recipient_delimiter = +).

you generally want mail for this address to be delivered to the mailbox
of j...@example.com (possibly in a "extension1" folder).

of course, if your LDA can "parse" addresses, then this handling may be
delegated to the LDA. but since postfix functionality comes for free...


Thanks for the pointer to pipe document, I had Googled, but I got a mass 
of not very useful hits.


OK, so if I got this right, were to continue using ${recipient} then I 
am passing /joe+extens...@example.com/ to the LDA which may not be good.


I assume that ${domain} is extracted from the recipient address and 
therefor might possible be blank (null), but in the case above should 
result in /example.com/. Therefore  ${user}@${domain} could give me /joe 
/(assuming an address of just/jo/e) or /j...@example.com/ (assuming the 
example above).


Whereas, it appears that ${nexthop} is either equals${domain} if the 
address is as above or ${mydomain} again assuming the the recipient 
address is just /joe,/ right?/


/If I am right, big if, then it would appear to be better to use 
${domain} rather than ${nexthop}.
However, rereading the Dovecot LDA docs I might be better using 
${recipient} as it appears that Dovecot parse the arguments anyway.


Oh well, back to the docs.

Thanks for the help, but I think I am going to do a lot more reading!

JohnA

Re: mailbox_coomand

[john]

On 19/05/2012 2:45 PM, mouss wrote:

Le 19/05/2012 16:50, john a écrit :

{snip]
Thanks for the pointer to pipe document, I had Googled, but I got a mass
of not very useful hits.


the official documentation of postfix can be found on
http://www.postfix.org/documentation.html
for the man pages, click on "All Postfix manual pages", which leads you to
http://www.postfix.org/postfix-manuals.html

and for all postfix parameters, click on "All main.cf parameters", which
leads you to
http://www.postfix.org/postconf.5.html




OK, so if I got this right, were to continue using ${recipient} then I
am passing /joe+extens...@example.com/ to the LDA which may not be good.

I assume that ${domain} is extracted from the recipient address and
therefor might possible be blank (null),

the domain is never empty. (unless you configure postfix not to append
@myroigin, which is highly discouraged).


but in the case above should
result in /example.com/. Therefore  ${user}@${domain} could give me /joe
/(assuming an address of just/jo/e) or /j...@example.com/ (assuming the
example above).

Whereas, it appears that ${nexthop} is either equals${domain} if the
address is as above or ${mydomain} again assuming the the recipient
address is just /joe,/ right?/


${nexthop} can be set by you in a transport entry.


/If I am right, big if, then it would appear to be better to use
${domain} rather than ${nexthop}.

if using postfix 2.5 or higher (the variable didn't exist before).


However, rereading the Dovecot LDA docs I might be better using
${recipient} as it appears that Dovecot parse the arguments anyway.


well, the risk is if you change the extension delimiter in postfix but
dovecot keeps using '+'. I prefer to handle the extension in postfix and
pass it via -m to dovecot.


Oh well, back to the docs.

Thanks for the help, but I think I am going to do a lot more reading!

JohnA


OK, just to tidy things up it would appear to me that I should use 
${user}@${domain}, and stick with -m ${extension}.


Once again thanks for your help.

JohnA

Postfix configuration optimization?

[john]

Are there any tools that would help in optimizing/tweaking the Postfix 
configuration?

Re: Thanks: Input requested: append_dot_mydomain default change

[John]

On 24/09/2014 10:29 AM, wie...@porcupine.org (Wietse Venema) wrote:

Thanks for the first-hand input, both on- and off-list.  The responses
show that there is a massive problem with what Rumsfeld called the
"unknown unknowns".

That is, except for those who have total control over their clients,
people generally have no idea what legacy systems might be sending
incomplete addresses, because everything has been working smoothly
over the past 10 or more years.

I will therefore implement a mechanism that preserves historical
defaults when upgrading from an older Postfix release. It will log
a reminder until the administrator executes a documented Postfix
command that accepts the new default after freezing any affected
main.cf or master.cf default setting at its legacy default value.

This will not rely on the automatic safety-net updates made by
"postfix upgrade-configuration" because down-stream maintainers
have sometimes implemented those selectively.

The implementation will probably be a compatibility_level parameter
that is 1 for installations that pre-date this feature, that is 2
for new installations, and that is incremented by 1 for each
compatibility break. People who don't care can set this to 99
and never hear a peep about compatibility breaks.

Wietse
First off I am not a particularly adept systems admin.I have made many 
mistakes in setting up my own systems and been saved by the from some of 
the more hideous mistakes by the people on this list.
That said  this seems like an awful lot of work on your part just to 
save people from their own ineptitude.
The idea of handing out email addresses that do not have a fully 
qualified domain in them seems to be rather dumb.
Surely it would be better in the long run to publish a strongly worded 
notice about the change, including some words on the "bad practice" of 
not using fqdn (anywhere).


Make the change to "no" after all if something breaks the admin can 
always turn it on by setting it to "yes".


Just my 2c worth.

OT: can anybody tell me what is wrong here

[John]

Sorry to bring this here but I cannot see what my problem is!! email to 
cogeco.ca is being rejected with the folowing message

 host MX.cogeco.ca[216.221.81.26] said: 451 Postmaster
 Code 5 - #4.1.8 Domain of sender address   does not resolve.
 Le domaine, utilis?? pour envoyer le courriel, ne se r??sout
 pas. (in reply to MAIL FROM command)


However every test that I perform comes back normal. I have also used offsite 
services such as MXtools, dnsstuff; neither of them show any problems.

What am I missing?

John A

DROP not a Postfix problem!!: OT: can anybody tell me what is wrong here

[John]

On 14/10/2014 11:14 PM, Claus Assmann wrote:

On Tue, Oct 14, 2014, John wrote:

 host MX.cogeco.ca[216.221.81.26] said: 451 Postmaster
  Code 5 - #4.1.8 Domain of sender address   does not resolve.

Try again, it's just a temporary error.

BTW: cool error message with those 8 bit chars in it:
utilisé pour envoyer le courriel, ne se résout pas

Re: DROP not a Postfix problem!!: OT: can anybody tell me what is wrong here

[John]

*Thank you.*
Yes that is/was the problem!
An automatic update to my system broke DNSSEC tools, so it did not roll, 
no roll, no notice to update the DLV 

Temp solution, drop DNSSEC while I try to fix the DNSSEC tools.
On 17/10/2014 6:55 AM, wie...@porcupine.org (Wietse Venema) wrote:

John:

On 14/10/2014 11:14 PM, Claus Assmann wrote:

On Tue, Oct 14, 2014, John wrote:

 host MX.cogeco.ca[216.221.81.26] said: 451 Postmaster
   Code 5 - #4.1.8 Domain of sender address   does not 
resolve.

Try again, it's just a temporary error.

BTW: cool error message with those 8 bit chars in it:
utilis? pour envoyer le courriel, ne se r?sout pas

Some REMOTE MAIL SERVER is not accepting your mail.  If you want
to know why, ask the people who are responsible for the REMOTE MAIL
SERVER.

Wietse

Re: google bouncing emails - ipv6 ptr problem?

[John]

On 11/22/2014 9:45 AM, Robert Schetterer wrote:

Am 22.11.2014 um 14:50 schrieb A. Schulze:

wietse:


A. Schulze:

So instead implementing strange workarounds, one should search, find,
understand and fix the real problem.

Google bounced my mail because of a temp error. I changed nothing
in my DNS or DKIM. It's their bug, not mine.

I don't expect your setup is obviously broken and also I don't want to
attack somebody. Sorry if that was misunderstood.

but in general I often notice people tend to claim it's *always*
Google's fault
which is simply not true /from my/ experience. I send >10k messages per day
to Google mx servers and never noticed such problems.
OK, maybe I'm in a magic Google whitelist because of my volume but I'm
not aware of this.


Hi Andreas , there a "wide" reports that google sometimes fails somehow
  with ipv6, i investigated in this hardly , it simply looks its their
bug, my best speculation goes in sometimes not working spf ipv6 stuff at
their site


Pardon me for butting in here, I am NOT a postfix expert and am 
reluctant to tell my betters what to do.


however, I had a similar problem a while back, Google would randomly 
reject email for, to me, no good reason.
It turned out that with IPv6 postfix was not consistent in binding an 
address for sending.
Google would do a RDNS lookup using the perceived address that the email 
came from, this would not resolve correctly, and Google would, correctly 
in my opinion, reject the email.


 My solution was to add smtp_bind_address stanzas to master.cf

==
smtpunix - -  n -  -  smtp
-o smtp_bind_address=74.nnn.nnn.178
-o smtp_bind_address6=2001:470:dead:beef:nn::178
==

Since making this change I have not had any problems is sending to Google.

Hope this helps

JohnA

Re: google bouncing emails - ipv6 ptr problem?

[John]

I forgot to add that the PTR records for both  74.nnn.nnn.178 and 
2001:470:dead:beef:nn::178 point to smtp.my.domain which matches the 
rest of my setup.

Re: google bouncing emails - ipv6 ptr problem?

[John]

On 11/23/2014 9:50 AM, wie...@porcupine.org (Wietse Venema) wrote:

John:

however, I had a similar problem a while back, Google would randomly
reject email for, to me, no good reason.
It turned out that with IPv6 postfix was not consistent in binding an
address for sending.

Please do not spread unnecessary confusion.

If you had read this tread more carefully, then you would see that
Google randomly rejects mail from the same site with correct PTR
configuration.

Here it is again: same message, same sender, same recipient,
same SMTP client IP address, same SMTP server IP address.

Nov 11 11:55:15 spike postfix/smtp[22958]: 3jcZv4004YzJrPw:
to=, relay=aspmx.l.google.com[2607:f8b0:400d:c04::1a]:25,
delay=3.6, delays=0.12/0.01/2.6/0.93, dsn=5.7.1, status=bounced
(host aspmx.l.google.com[2607:f8b0:400d:c04::1a] said: 550-5.7.1
[2604:8d00:189::2] Our system has detected that this message does
not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records
and authentication 550-5.7.1 . Please review 550-5.7.1
https://support.google.com/mail/?p=ipv6_authentication_error for
more 550 5.7.1 information. l17si30149401qaj.81 - gsmtp (in reply
to end of DATA command))

Nov 11 11:58:29 spike postfix/smtp[22980]: 3jcZyr2BpqzJrPw:
to=, relay=aspmx.l.google.com[2607:f8b0:400d:c04::1a]:25,
delay=1.4, delays=0.11/0.01/0.19/1.1, dsn=2.0.0, status=sent (250
2.0.0 OK 1415725109 k30si37581932qge.88 - gsmtp)

Wietse

This EXACTLY what was happening to me.

I spent a couple of weeks trying to figure what the hell was wrong, 
everything seemed to be absolutely right. IPv4 worked without a so much 
as a pause for breath. IPv6 would fail for no discernible reason! RDNS 
records were correct, both IPv4 and 6.
In the end I saw a posting on a message board (it may have been this 
one) about the problem and it recommended adding smtp_bind_address(6) to 
the smtp config in master. I did so and the problem disappeared, I don't 
know why all I know is it worked.
I did wonder if it might be a DNS problem. Is/was IPv6 RDNS slower to 
respond, particularly as I am using HE.net for IPv6? Does the 6 RDNS 
request time out and Google takes that as a negative answer?
If you can explain why adding the stanzas to master "cures" the problem 
I am all ears!

JohnA

Maybe OT: SPF records

[John]

Are SPF DNS records deprecated. i was checking my setup using MXTools 
and it comes back with a warning then SPF records are no longer 
"supported".

When I look for docs on the internet, I get two answers( 3 actually)
a) no they are current,
b) they have been dropped,
c) articals that only discuss TXT records

a) + b) are usually more recent, c) can be any age.

And just to make life a little more interesting, the Bind9 log show an 
entry "general: warning: zone klam.ca/IN/external: 'klam.ca' found 
SPF/TXT record but no SPF/SPF record found, add matching type SPF recor..."!


Not a life or death issue, just a confusing!

John A

Closed: Maybe OT: SPF records

[John]

On 12/8/2014 1:30 AM, Scott Kitterman wrote:

On December 7, 2014 12:28:12 PM EST, John  wrote:

Are SPF DNS records deprecated. i was checking my setup using MXTools
and it comes back with a warning then SPF records are no longer
"supported".
When I look for docs on the internet, I get two answers( 3 actually)
a) no they are current,
b) they have been dropped,
c) articals that only discuss TXT records

a) + b) are usually more recent, c) can be any age.

And just to make life a little more interesting, the Bind9 log show an
entry "general: warning: zone klam.ca/IN/external: 'klam.ca' found
SPF/TXT record but no SPF/SPF record found, add matching type SPF
recor..."!

Not a life or death issue, just a confusing!

John A

Support for use of DNS Type SPF (99) was dropped from RFC 7208, the recently 
published standards track update to RFC 4408.

Further discussion would be on topic on spf-help or spf-discuss.   See 
www.openspf.org/Forums for subscription information.



Thanks the info on the SPF forums. I will take a look there when I have 
a minute.

Re: A highly goofed installation Postfix/Dovecot/Squirrelmail

[John]

OK. So these are a little dated.
Any recommendations for HOWTOs that are a more up to date.


On 12/13/2014 5:33 PM, Bill Cole wrote:

On 12 Dec 2014, at 22:47, ghalvor...@hushmail.com wrote:


Hello friends,

I followed a HOWTO document and it wasn't an entire success.  I do 
want to be more proficient with Postfix and have bought The Book of 
Postfix from No Starch and Postfix: The Definitive Guide from 
O'Reilly.  I've spent about 15 hours in each book, so hopefully I 
have a vague idea of how it works.


Note that those are both quite old. They are solid references for 
their times and because Dr. Venema is very careful about backward 
compatibility they are mostly not wrong, but they cannot help you with 
the setup of the many features added to Postfix in the past 8-10 years.



The HOWTO is:

https://www.digitalocean.com/community/tutorials/how-to-configure-a-mail-server-using-postfix-dovecot-mysql-and-spamassasin 



That seems a bit more modern, but it is mostly instructions for 
operating Things That Are Not Postfix.


[...]
So when I send a test email from my MacBook using mail in the command 
line, I get these in mail.log.  I get many, many of these.  For now, 
I'm mainly concerned with the postfix error.  The Dovecot stuff, I 
can refer to their list once the Postfix is in good shape.  The 
/var/spool/ and /var/mail/ directories seem to be unchanged, which is 
a bit disturbing (maybe a permissions problem?)


Dec 12 21:52:06 example postfix/qmgr[29911]: 21EDCC08A3: 
from=, size=578, nrcpt=1 (queue active)

Dec 12 21:52:06 example dovecot: lmtp(30139): Connect from local
Dec 12 21:52:06 example dovecot: lmtp(30139, b...@example.com): Error: 
user b...@example.com: Initialization failed: namespace configuration 
error: inbox=yes namespace missing
Dec 12 21:52:06 example dovecot: lmtp(30139): Disconnect from local: 
Successful quit
Dec 12 21:52:06 example postfix/lmtp[30138]: 21EDCC08A3: 
to=, relay=example.com[private/dovecot-lmtp], 
delay=1021, delays=1021/0.02/0.02/0.04, dsn=4.3.0, status=deferred 
(host example.com[private/dovecot-lmtp] said: 451 4.3.0 
 Temporary internal error (in reply to end of DATA 
command))


That is entirely a Dovecot problem. The first line is purely 
informational and the final line is just a record of the Dovecot LMTP 
response.

DNSSEC - DANE

[John]

I have setup my DNS server for DNSSEC + DANE. I am using inline signing 
on Bind9 and it appears to be working for HTTPS access.
I have a minor problem with key rolling, it seems to be a rather 
cumbersome process at the moment, but I suspect that it is me rather 
than the process.


Having got it working for HTTPS, I felt that I could move on to 
implementing it for SMTP (Postfix).

First question is how do I test it to determine if it is working or not?
The testing I have done to date seems to indicate that it is not 
working, but I am not sure why not?


/Log file output/
===
Dec 30 19:16:33 bilbo postfix/smtpd[3366]: connect from 
mail-la0-x22c.google.com[2a00:1450:4010:c03::22c]
Dec 30 19:16:35 bilbo postfix/smtpd[3366]: 30CFB36401D2: 
client=mail-la0-x22c.google.com[2a00:1450:4010:c03::22c]
Dec 30 19:16:35 bilbo postfix/cleanup[3375]: 30CFB36401D2: 
message-id=
Dec 30 19:16:35 bilbo postfix/qmgr[3359]: 30CFB36401D2: 
from=, size=2238, nrcpt=1 (queue active)
*Dec 30 19:16:35 bilbo postfix/smtp[3376]: warning: [127.0.0.1]:10024: 
dane configured with dnssec lookups disabled*
Dec 30 19:16:35 bilbo postfix/smtpd[3366]: disconnect from 
mail-la0-x22c.google.com[2a00:1450:4010:c03::22c]

Dec 30 19:16:40 bilbo postfix/smtpd[3381]: connect from localhost[127.0.0.1]
Dec 30 19:16:40 bilbo postfix/smtpd[3381]: 61EB336401EC: 
client=localhost[127.0.0.1]
Dec 30 19:16:40 bilbo postfix/cleanup[3382]: 61EB336401EC: 
message-id=
Dec 30 19:16:40 bilbo postfix/smtpd[3381]: disconnect from 
localhost[127.0.0.1]
Dec 30 19:16:40 bilbo postfix/qmgr[3359]: 61EB336401EC: 
from=, size=2762, nrcpt=1 (queue active)
Dec 30 19:16:40 bilbo postfix/smtp[3376]: 30CFB36401D2: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=5.5, 
delays=0.52/0.01/0.01/4.9, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 61EB336401EC)

Dec 30 19:16:40 bilbo postfix/qmgr[3359]: 30CFB36401D2: removed--
===

Does the line I have highlighted indicate that DANE I being disabled 
because of AMAVIS, if so how do I ensure that it only disabled on the 
internal network.


John Allen
KLaM
--
A day without sunshine is like, night?
; zone file for klam.ca

$ORIGIN klam.ca.
$TTL 1H

@   IN SOA  ns0.klam.ca. admin.klam.ca. 2014123005 
4H 1H 2W 1H

IN NS   ns0.klam.ca.
IN NS   ns1.klam.ca.

ns0 IN A74.116.186.178
IN  2001:470:b183:10::178
ns1 IN A74.116.186.186
IN  2001:470:b183:10::186


@   IN A74.116.186.178
IN  2001:470:b183:10::178

@   IN MX   10 smtp.klam.ca.

@   IN TXT  "v=spf1 a mx ptr ip4:74.116.186.178 
ip6:2001:470:b183:10::178 mx:smtp.klam.ca. -all"

@   IN NSEC3PARAM 1 0 10 8f2b679412956535

dkim._domainkey IN TXT  "v=DKIM1; 
p=M..QAB"

_25._tcp.smtp   IN TLSA ( 3 0 1 
5bab )
_587._tcp.smtp  IN TLSA ( 3 0 1 
5bab )

_443._tcp.www   IN TLSA ( 3 0 1 
14d1 )
_443._tcp.dav   IN TLSA ( 3 0 1 
14d1 )
_443._tcp.davical   IN TLSA ( 3 0 1 
14d1 )


smtpIN A74.116.186.178
IN  2001:470:b183:10::178
sieve   IN A74.116.186.178
IN  2001:470:b183:10::178
imapIN A74.116.186.178
IN  2001:470:b183:10::178

www IN A74.116.186.179
IN  2001:470:b183:10::179

postfixadminIN A74.116.186.179
IN  2001:470:b183:10::179
pgadmin IN A74.116.186.179
IN  2001:470:b183:10::179

filelinkIN A74.116.186.179
IN  2001:470:b183:10::179

dav IN A74.116.186.180
IN  2001:470:b183:10::180

carddav IN A74.116.186.181
IN  2001:470:b183:10::181
calendarIN A74.116.186.181
IN  2001:470:b183:10::181
davical IN

Re: DNSSEC - DANE

[John]

On 12/30/2014 7:58 PM, wie...@porcupine.org (Wietse Venema) wrote:

Wietse Venema:

John:

*Dec 30 19:16:35 bilbo postfix/smtp[3376]: warning: [127.0.0.1]:10024:
dane configured with dnssec lookups disabled*

Have you noticed the "unused parameter" warning for smtp_dns_supporta_level?

That is, when you use the postconf command to show the
configuration that Postfix actually uses.

Wietse
That is what comes of making last minute changes. the "a" was part of 
another document that I was editing, I failed to shift focus.


--
John Allen
KLaM
--
You are off the edge of the map, mate. Here there be monsters!

Re: DNSSEC - DANE

[John]

On 12/30/2014 11:19 PM, Viktor Dukhovni wrote:

On Tue, Dec 30, 2014 at 07:47:24PM -0500, John wrote:


I have setup my DNS server for DNSSEC + DANE. I am using inline signing on
Bind9 and it appears to be working for HTTPS access.
I have a minor problem with key rolling, it seems to be a rather cumbersome
process at the moment, but I suspect that it is me rather than the process.

Having got it working for HTTPS, I felt that I could move on to implementing
it for SMTP (Postfix).

For inbound DANE TLS you're all set.  My work-in-progress danecli
shows:

 $ danecli -mg klam.ca
 klam.ca. IN MX 10 smtp.klam.ca. ; NOERROR AD=1 1/0 1/0/1
 smtp.klam.ca. IN A 74.116.186.178 ; passed
 _25._tcp.smtp.klam.ca. IN TLSA 3 0 1 
5bf12300255d1475ae43677b7062ab8964ca097ee6096cd005115b8c974e83ab ; passed at 
depth=0
 smtp.klam.ca. IN  2001:470:b183:10:0:0:0:178 ; connerr: Connection 
timed out

Which means that smtp.klam.ca has a working TLSA RRset, but perhaps
has IPv6 connectivity issues.

As for key rotation, see:

 https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1
 https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4


smtp_use_tls = yes

This is obsolete, superseded by smtp_tls_security_level below:


smtp_tls_security_level = dane

And likewise:


smtpd_use_tls = yes
smtpd_tls_security_level = may


Just so I get this right "/smtpd_tls_security_level = dane/" is 
acceptable, I ask because I did not find this in the postfix docs.

Do I also need "smtpd_dns_support_level = dnssec"
answered my own ? postconf tosses out smtpd...= dnssec and accepts 
smtpd...= dane.

Are there any other gotchas that I should be aware of.

Thank you very much for the the test.
Yes I have a intermittent IPv6  problem - my ISP.  To get IPv6 
connectivity I have to use HE.net tunnel broker as my ISP is/thinking/ 
about IPv6. I suspect that as they are resellers for Bell Canada he is 
waiting for them to get off their butts. 98% of the time there is no 
problem but every so often IPv6 just stop working. This appears to be 
one of them.


--
John Allen
KLaM
--
In the world of the internet
if you're not paying for something, you're not the customer;
you are the product being sold
/from the blue_beetle/

Re: DNSSEC - DANE

[John]

https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1
https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4

Both of the above return "object not found" I assume that as they are 
both draft docs they come and go as the editors update them.
I will keep an eye on the site, hopefully catch them next time they are 
available.


--
John Allen
KLaM
--
OK, so what is the speed of dark?

Re: DNSSEC - DANE

[John]

/smtpd_tls_security_level = dane/.

postconf does not show any error for the above, but postfix itself does 
"fatal: invalid TLS level "dane" - I have switched back to may


--
John Allen
KLaM
--
You are off the edge of the map, mate. Here there be monsters!

New year

[John]

Here is wishing you all a very happy and prosperous new year.
--
John Allen
KLaM
--
Support bacteria. There are the only culture some people have.

Re: DNSSEC - DANE

[John]

On December 31, 2014 12:37:52 PM Viktor Dukhovni 
 wrote:



On Wed, Dec 31, 2014 at 12:45:20AM -0500, John wrote:

> https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1
> https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4

Sorry,


Don't worry about it.



https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4

> Both of the above return "object not found" I assume that as they are both
> draft docs they come and go as the editors update them.

Well, no, IETF documents are retained indefinitely.

--
Viktor.

Postfix + Davical

[John]

We use davical for our address book,.
It occurred to me that anybody who was in address book should probably 
pass the sender access check.
So I created the following postgresql query, however it does not seem to 
work. I am not a SQL of any sort expert, so would somebody mind taking a 
look and telling me what I have screwed up.


*/SELECT CASE WHEN count(DISTINCT email) =1 then 'OK' ELSE 'DUNNO' END/**/
/**/FROM addressbook_address_email WHERE addressbook_address_email.email 
= '%s';/*


--
John Allenpost
KLaM
--
OK, so what is the speed of dark?

Postfix + Davical RE-SENT

[John]

I am resubmitting this as I am not sure it made it out the door, System 
crash.



We use davical for our address book,.
It occurred to me that anybody who was in address book should probably 
pass the sender access check.
So I created the following postgresql query, however it does not seem to 
work. I am not a SQL of any sort expert, so would somebody mind taking a 
look and telling me what I have screwed up.


*/SELECT CASE WHEN count(DISTINCT email) =1 then 'OK' ELSE 'DUNNO' END/**/
/**/FROM addressbook_address_email WHERE addressbook_address_email.email 
= '%s';/*


--
John Allenpost
KLaM
--
OK, so what is the speed of dark?

Re: DANE and DLV

[John]

I assume this list is "best" to "worst"

; Use "3 1 1", the other three are OK, but "3 1 1" is better.
_25._tcp.mx.example.com. IN TLSA 3 1 1 
_25._tcp.mx.example.com. IN TLSA 3 0 1 
_25._tcp.mx.example.com. IN TLSA 3 1 2 
_25._tcp.mx.example.com. IN TLSA 3 0 2 

; Use "2 0 1", the other three are OK, but "2 0 1" is better.
_25._tcp.mx.example.com. IN TLSA 2 0 1 
_25._tcp.mx.example.com. IN TLSA 2 1 1 
_25._tcp.mx.example.com. IN TLSA 2 0 2 
_25._tcp.mx.example.com. IN TLSA 2 1 2 

I am not sure I understand this. Why are you linking the two?

 * Do understand how to coordinate DANE TLSA record updates with
   key rotation, and never forget to update DANE TLSA records
   as part of that process.
Has anybody published any recommendations as to timing for the life 
cycle of a ZSK  (and KSK for that matter)? So far the only 
recommendation I have seen was a footnote in a paper on DNSSEC. It 
recommended 1yr for KSK and 4Yrs for KSKs. I think these number are 
unrealistic for a couple of reasons 1) with the growth of hacker nets i 
do not think keys can survive that long. 2) on a much more mundane level 
- with staff turn over etc., rollover is  liable to slip between the cracks.


Are there any know tools to automate rollover? I have not found any and 
have been writing my own script but being a lazy s.. i would prefer to 
use somebody elses work!


Victor - I have a question and a suggestion which I would like to 
explore offline. May I contact you at IETF, or at any other address you 
like, you may contact me a j...@klam.ca.


--
John Allen
KLaM
--
You are off the edge of the map, mate. Here there be monsters!

Re: DANE and DLV

[John]

On 1/7/2015 1:22 PM, Viktor Dukhovni wrote:

I am not sure I understand this. Why are you linking the two?
I am not linking anything.
I am not sure what TLSA updates has to do with key rotation, other than 
they might be a good idea to do them at the same time. May be its my odd 
ball way of reading it.

 * Do understand how to coordinate DANE TLSA record updates with
   key rotation, and never forget to update DANE TLSA records
   as part of that process.




--
John Allen
KLaM
--
A day without sunshine is like, night?

Re: hold trigger dmarc milter notify_classes

[John]

Dumb question. Are all holds to be found in the (debian case) in the 
/var/spool/postfix/hold space? If so the surely a simple script that sends 
a message to root (?) if the folder is not empty might be a stop gap solution.