Re: Complaints due to helo restrictions

[Nikolaos Milas]

On 13/9/2016 8:52 μμ, Wietse Venema wrote:


I'd use none of these.


Thank you all for your feedback. Following Wietse's advice, I have 
removed these directives from the config.


All the best,
Nick

Effects of very large message_size_limit?

[mrobti]

Hi, I'm wondering what the downside of setting a large 
message_size_limit are?


By "large" I mean 30MB, 40MB, 50MB

I think sendmail has a default of no restriction for message size - that 
seems crazy, but maybe I don't understand the risks well enough.

Re: mysql lookup table and utf8

[Phil Stracchino]

On 09/14/16 19:29, Wietse Venema wrote:
 Perhaps Postfix needs to try to explicitly load the default config
 location when no override is set.
>>>
>>> How do we do that, without hard-coding '/etc/my.cnf' into Postfix?
>>> That pathname is almost certainly incorrect on systems like *BSD
>>> that install ports configuration files outside the base system
>>> directory tree.
>>
>> It will even be incorrect on many Linux distributions (Ubuntu for
>> example), many of which default to /etc/mysql/ instead of /etc/.
> 
> Isn't this pathname defined in some #include file?  How do other
> client programs find out where the default location is?

Well, it's supposed to Just Work if they're using libmysqlclient.  I'm
not sure where to get the information of NOT using libmysqlclient, other
than just searching likely locations.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485

Re: mysql lookup table and utf8

[Wietse Venema]

> >> Perhaps Postfix needs to try to explicitly load the default config
> >> location when no override is set.
> > 
> > How do we do that, without hard-coding '/etc/my.cnf' into Postfix?
> > That pathname is almost certainly incorrect on systems like *BSD
> > that install ports configuration files outside the base system
> > directory tree.
> 
> It will even be incorrect on many Linux distributions (Ubuntu for
> example), many of which default to /etc/mysql/ instead of /etc/.

Isn't this pathname defined in some #include file?  How do other
client programs find out where the default location is?

Wietse

Re: mysql lookup table and utf8

[Paul]

On 14/09/2016 22:07, Phil Stracchino wrote:

On 09/14/16 13:44, Wietse Venema wrote:

Viktor Dukhovni:

On Wed, Sep 14, 2016 at 06:07:22PM +0200, Antoine Nguyen wrote:


Looks like I've found the issue. Actually, the mysql connector does not read
the default /etc/my.cnf file (or at least the package I installed for CentOS
7).

Perhaps Postfix needs to try to explicitly load the default config
location when no override is set.

How do we do that, without hard-coding '/etc/my.cnf' into Postfix?
That pathname is almost certainly incorrect on systems like *BSD
that install ports configuration files outside the base system
directory tree.

It will even be incorrect on many Linux distributions (Ubuntu for
example), many of which default to /etc/mysql/ instead of /etc/.


I wonder if there is a different way to make clients read /etc/my.cnf.
I also wonder why they don't read that file by default.

"It depends."  As a rule, MySQL clients *do* read $sysconfigdir/my.cnf
and ${HOME}/.my.cnf by default, if they exist.  But when you have MySQL
packages and MySQL clients built with conflicting ideas of where
$sysconfigdir should be, things start to fall apart.  This problem is
going to exist anywhere except an Apple-like walled garden.

There exists a Linux Filesystem Standard that lays out in general terms
what should be expected to be where.  There are many distributions that
follow it.  There are also many that don't.  And then you get into *BSD,
and Solaris, and...



Just maybe my.cnf and it's  path needs  to be /var/spool/postfix/etc 

Paul

Re: mysql lookup table and utf8

[Phil Stracchino]

On 09/14/16 13:44, Wietse Venema wrote:
> Viktor Dukhovni:
>> On Wed, Sep 14, 2016 at 06:07:22PM +0200, Antoine Nguyen wrote:
>>
>>> Looks like I've found the issue. Actually, the mysql connector does not read
>>> the default /etc/my.cnf file (or at least the package I installed for CentOS
>>> 7).
>>
>> Perhaps Postfix needs to try to explicitly load the default config
>> location when no override is set.
> 
> How do we do that, without hard-coding '/etc/my.cnf' into Postfix?
> That pathname is almost certainly incorrect on systems like *BSD
> that install ports configuration files outside the base system
> directory tree.

It will even be incorrect on many Linux distributions (Ubuntu for
example), many of which default to /etc/mysql/ instead of /etc/.

> I wonder if there is a different way to make clients read /etc/my.cnf.
> I also wonder why they don't read that file by default.

"It depends."  As a rule, MySQL clients *do* read $sysconfigdir/my.cnf
and ${HOME}/.my.cnf by default, if they exist.  But when you have MySQL
packages and MySQL clients built with conflicting ideas of where
$sysconfigdir should be, things start to fall apart.  This problem is
going to exist anywhere except an Apple-like walled garden.

There exists a Linux Filesystem Standard that lays out in general terms
what should be expected to be where.  There are many distributions that
follow it.  There are also many that don't.  And then you get into *BSD,
and Solaris, and...


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485

Re: mysql lookup table and utf8

[Bastian Blank]

On Wed, Sep 14, 2016 at 04:14:57PM +, Viktor Dukhovni wrote:
> > @Viktor Do you confirm it is not currently possible to host UTF8 domains
> > with a postgres backend ?
> I don't believe it is.  We probably need to make that "LATIN1"
> configurable via the ".cf" file.

I'm curious what just hardcoding this to UTF-8 would break.  The input
should never be LATIN1, only either ASCII or UTF-8.

Bastian

-- 
There are some things worth dying for.
-- Kirk, "Errand of Mercy", stardate 3201.7

Re: mysql lookup table and utf8

[Wietse Venema]

Viktor Dukhovni:
> On Wed, Sep 14, 2016 at 06:07:22PM +0200, Antoine Nguyen wrote:
> 
> > Looks like I've found the issue. Actually, the mysql connector does not read
> > the default /etc/my.cnf file (or at least the package I installed for CentOS
> > 7).
> 
> Perhaps Postfix needs to try to explicitly load the default config
> location when no override is set.

How do we do that, without hard-coding '/etc/my.cnf' into Postfix?
That pathname is almost certainly incorrect on systems like *BSD
that install ports configuration files outside the base system
directory tree.

> When "option_file" is not set we currently do nothing, and let the
> MySQL libraries do whatever they do by default.

I wonder if there is a different way to make clients read /etc/my.cnf.
I also wonder why they don't read that file by default.

Wietse

Postfix transport - master_service_disable

[postadmin]

Hi List

 

Hoping to clarify if remote transport mappings can be restricted.

 

At this point it appears that master_service_disable allows for specific
listeners to be disabled.

 

However the type of listener/service specific to transport mappings "587
submission" is unclear.

 

Essentially transport mappings are currently bypassing the unix spamc.

 

If possible please clarify if transport mappings can be restricted or
"forwarded" to the unix spamc.

 

Regards

Patrick

Re: mysql lookup table and utf8

[Viktor Dukhovni]

On Wed, Sep 14, 2016 at 06:07:22PM +0200, Antoine Nguyen wrote:

> Looks like I've found the issue. Actually, the mysql connector does not read
> the default /etc/my.cnf file (or at least the package I installed for CentOS
> 7).

Perhaps Postfix needs to try to explicitly load the default config
location when no override is set.  When "option_file" is not set
we currently do nothing, and let the MySQL libraries do whatever
they do by default.

> Adding:
> 
> option_file = /etc/my.cnf
> 
> At the beginning map.cf file fixes the problem because I set utf8 as the
> default client encoding in the general mysql config.

This makes sense.

> @Viktor Do you confirm it is not currently possible to host UTF8 domains
> with a postgres backend ?

I don't believe it is.  We probably need to make that "LATIN1"
configurable via the ".cf" file.

-- 
Viktor.

Re: mysql lookup table and utf8

[Viktor Dukhovni]

On Wed, Sep 14, 2016 at 05:39:50PM +0200, Antoine Nguyen wrote:

> >Yes, the Postgres driver is unconditionally LATIN1 at present.
>
> And this limitation does not exist with the mysql one ?

No.  Nothing in Postfix explicitly sets the MySQL client encoding.
Perhaps that's needed for utf-8 (i.e. does not default from LANG,
...).  Don't know the MySQL API at all, so someone who's familiar
with that will have to chime in.

-- 
Viktor.

Re: mysql lookup table and utf8

[Antoine Nguyen]

On 14/09/2016 14:53, Viktor Dukhovni wrote:


Please look for any client-side configuration files that might be
loaded by the MySQL interactive shell that may affect connection
settings, such as perhaps the client character set.



Looks like I've found the issue. Actually, the mysql connector does not 
read the default /etc/my.cnf file (or at least the package I installed 
for CentOS 7).


Adding:

option_file = /etc/my.cnf

At the beginning map.cf file fixes the problem because I set utf8 as the 
default client encoding in the general mysql config.


Thanks for your help !

@Viktor Do you confirm it is not currently possible to host UTF8 domains 
with a postgres backend ?


Antoine

Re: mysql lookup table and utf8

[Antoine Nguyen]

On 14/09/2016 17:06, Viktor Dukhovni wrote:

On Wed, Sep 14, 2016 at 04:14:32PM +0200, Antoine Nguyen wrote:


I haven't found how to change default client encoding yet... Does postfix
set it ?

Sorry to reply to myself but looks like the answer is here:

https://github.com/vdukhovni/postfix/blob/506a3e8993d1d73b397a113b89319ff997e8673b/postfix/src/global/dict_pgsql.c#L644

Yes, the Postgres driver is unconditionally LATIN1 at present.


And this limitation does not exist with the mysql one ?

Antoine

Re: (ot) beware libressl on Freebsd

[lists]

I'm fixing a few other problems due to the upgrade, but will follow up on 
libressl eventually. 

I'm a long time Linux user, but only have been using Freebsd for a little over 
a year, so I am cautious to do any rants. ;-)  (I have endured the wrath of 
Linux users mocking Yast, but I have yet to do an update of Freebsd without 
breaking something.)‎

Here is a similar thread to my issue:
‎https://forums.freebsd.org/threads/56398/

Right now, I'm just issuing a warning until I rule out pilot error.

  Original Message  
From: Jeffrey 'jf' Lim
Sent: Monday, September 12, 2016 3:17 PM
To: Postfix users
Subject: Re: (ot) beware libressl on Freebsd

On Tue, Sep 13, 2016 at 6:13 AM,  wrote:
> Freebsd 10.3
>
> I ran freebsd "pkg" ‎and didn't see any of the mail suite or openssl in the
> list of files to update, so I figured it was safe to run. (I've been burnt
> by pkg messing up dovecot or postfix, so I always use the ports).
>
> Some program must of needed libressl and openssl got replaced, breaking my
> email. Even reinstalling openssl wasn't sufficient because any program
> using openssl broke. SpamAssassin was having none of this, so I ended up
> reinstalling the whole email suite. No con file issues fortunately.
>
> Openssl and libressl have a conflict, so I had uninstalled libressl prior to
> reinstalling openssl.
>
> I think ntp was the program that wanted libressl. It didn't occur to me the
> program even used TLS
>

have you reported this to the any of the freebsd list(s)?

-jf

Re: mysql lookup table and utf8

[Viktor Dukhovni]

On Wed, Sep 14, 2016 at 04:14:32PM +0200, Antoine Nguyen wrote:

> >I haven't found how to change default client encoding yet... Does postfix
> >set it ?
> 
> Sorry to reply to myself but looks like the answer is here:
> 
> https://github.com/vdukhovni/postfix/blob/506a3e8993d1d73b397a113b89319ff997e8673b/postfix/src/global/dict_pgsql.c#L644

Yes, the Postgres driver is unconditionally LATIN1 at present.

-- 
Viktor.

Re: mysql lookup table and utf8

[Antoine Nguyen]

On 14/09/2016 16:09, Antoine Nguyen wrote:
As I said, I made some tests with postgres and I think I found an 
interesting hint inside logs:


LOG:  statement: set client_encoding to 'LATIN1'

LOG:  statement: SELECT name FROM admin_domain WHERE name='raté.com' 
AND type='domain' AND enabled


This is the result of postmap execution, it uses LATIN1 as encoding 
and not UTF8... (whereas server default encoding is UTF8 and my 
shell's current locale is en_US.UTF-8)


I haven't found how to change default client encoding yet... Does 
postfix set it ?


Sorry to reply to myself but looks like the answer is here:

https://github.com/vdukhovni/postfix/blob/506a3e8993d1d73b397a113b89319ff997e8673b/postfix/src/global/dict_pgsql.c#L644

Antoine

Re: mysql lookup table and utf8

[Antoine Nguyen]

On 14/09/2016 14:53, Viktor Dukhovni wrote:


Please post a single message with two complete traces in which:

* The Unix login users executing "postmap -q" and using the
  MySQL shell are the same.  (That is the same unix shell spawns
  both "postmap -q" and the MySQL interactive session).

* The target MySQL database name and database user are clearly
  identified in both cases.

* The queries and results are reported in detail.

Please look for any client-side configuration files that might be
loaded by the MySQL interactive shell that may affect connection
settings, such as perhaps the client character set.

As I said, I made some tests with postgres and I think I found an 
interesting hint inside logs:


LOG:  statement: set client_encoding to 'LATIN1'

LOG:  statement: SELECT name FROM admin_domain WHERE name='raté.com' AND 
type='domain' AND enabled

This is the result of postmap execution, it uses LATIN1 as encoding and 
not UTF8... (whereas server default encoding is UTF8 and my shell's 
current locale is en_US.UTF-8)


I haven't found how to change default client encoding yet... Does 
postfix set it ?


Antoine

Re: mysql lookup table and utf8

[Viktor Dukhovni]

On Wed, Sep 14, 2016 at 02:33:47PM +0200, Antoine Nguyen wrote:

> >>> SELECT name FROM admin_domain WHERE name='' AND 
> >>> type='domain' AND enabled=1
> >>>
> >>I've enabled queries logging. Here is the result :
> >>
> >>160914  8:24:14   57 QuerySELECT name FROM admin_domain WHERE 
> >>name='gaël.com' AND type='domain' AND enabled=1
> >>160914  8:24:31   60 Connectmodoboa@localhost as anonymous on 
> >>modoboa
> >>   60 QuerySELECT name FROM admin_domain WHERE 
> >> name='gaël.com' AND type='domain' AND enabled=1
> >>   60 Quit
> >>
> >>The first query was executed using mysql shell and it returns 1 row. The
> >>second query was executed by postmap and returns nothing whereas we can see
> >>they are the same...
> >Do post the "Connect" string for *both* queries.
> >
> Here is the missing line :
> 
> 160914  8:23:5757 Connect   root@localhost as anonymous on modoboa
> 
> I indeed tried with root but result is the same if I use modoboa user with
> mysql shell: it works.

Please post a single message with two complete traces in which:

   * The Unix login users executing "postmap -q" and using the
 MySQL shell are the same.  (That is the same unix shell spawns
 both "postmap -q" and the MySQL interactive session).

   * The target MySQL database name and database user are clearly
 identified in both cases.

   * The queries and results are reported in detail.

Please look for any client-side configuration files that might be
loaded by the MySQL interactive shell that may affect connection
settings, such as perhaps the client character set.

-- 
Viktor.

Re: After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

[Dominic Raferd]

Thanks for your quick reply Viktor. OK now I understand that what I am
trying to do can't be done. If someone could implement the feature you
suggest (wrapper mode is enabled conditionally, only when the port is 465,
and not when it is some other port) that would of course be ideal.

Background: smtp.virginmedia.net imposes some absurdly small limit on the
number of emails it will relay, I suppose because they deem it a
residential service. The reason I am trying to do this is that our 'normal'
relay server signs all emails (dkim) and this is good for emails we are
sending out but not good for emails we are receiving in (because these can
include all sorts of spam, and the signing falsely indicates them to be
from us), so I wanted to use Virgin's smtp server - which doesn't re-sign
emails - just to handle these incoming emails (and pass them on to our real
external mailboxes). Clearly I have to think again!

Apologies for double-posting my original question, I thought the first one
had not got through.

Dominic

On 14 September 2016 at 13:30, Viktor Dukhovni 
wrote:

> On Wed, Sep 14, 2016 at 01:11:53PM +0100, Dominic Raferd wrote:
>
> > I am using Postfix 3.1.0 and following instructions at
> > http://www.postfix.org/TLS_README.html#client_smtps to set up for
> sending
> > some (recipient dependent) emails via smtps (whereas others go over TLS
> to
> > a different relay server).
>
> Otherwise also called "TLS wrapper mode" in which a TLS handshake
> takes place immediately after the TCP 3-way hanshake, and the SMTP
> session runs inside TLS.  Note that:
>
> smtp_tls_wrappermode = yes
>
> is a global setting for the transport, that is, it depends only
> on the transport used, not the nexthop domain.
>
> >  So when it fails, Postfix falls back using the hosts
> > specified in main.cf's smtp_fallback_relay (*not* relayhost, which is
> used
> > for emails that don't have a match in the transport list).
>
> It does not matter whether "smtp_fallback_relay" is in main.cf or
> in master.cf specified per transport.   Either way, the fallback
> delivery always uses the same transport agent used for the primary
> nexthop.  Which means that smtp_fallback_relay will use smtps,
> when the primary nexthop uses smtps.  This does not depend on
> the nexthop destination's port number.
>
> What you're looking for is a new feature, in which wrapper mode is
> enabled conditionally, only when the port is 465, and not when it
> is some other port.  That code has not been written.
>
> It is hard to imagine why an MSA on port 465 would implement quotas.
> Generally, port 465 MSAs just do outbound submission, and not
> inbound mailbox delivery.  Is there some provider that's mixing
> up these services?  Is this configuration self-inflicted?
>
> If the primary MSA provider also supports STARTTLS on port 587,
> use that instead, and don't enable TLS wrapper mode.
>
> --
> Viktor.
>

After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

[Dominic Raferd]

I am using Postfix 3.1.0 and following instructions at 
http://www.postfix.org/TLS_README.html#client_smtps 
to set up for 
sending some (recipient dependent) emails via smtps (whereas others go 
over TLS to a different relay server). This uses the transport_maps 
settings inmain.cf , a transport file (hashed) and 
special routing (relay-smtps) inmaster.cf .


This works - when the onward smtps server accepts the emails. However in 
my case this doesn't always happen -  they sometimes block when we are 
over quota. So when it fails, Postfix falls back using the hosts 
specified inmain.cf 's smtp_fallback_relay (*not* 
relayhost, which is used for emails that don't have a match in the 
transport list).


All well and good. But I find that after smtps rejection, the 
fallback_relay hosts (both) always fail too with message like:


warning: TLS library problem: error:140770FC:SSL 
routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:


With the effect that the email cannot be sent at all.

In short like this:
/etc/postfix/main.cf 
transport_maps = hash:/etc/postfix/transport
relayhost = [smtp.send.net ]
smtp_fallback_relay = [relay.grad.net 
] [smtp.send.net 
]


/etc/postfix/transport and /etc/postfix/main.cf - 
as specified atTLS_README.html (above)for Postfix >= 3.0


However if I remove the initial attempt to use smtps (i.e. comment out 
transport_maps and reload postfix), then relayhost and fallback_relays 
work perfectly.


I've tried a raft of different settings without success. Any suggestions 
gratefully received.

Re: mysql lookup table and utf8

[Antoine Nguyen]

On 14/09/2016 14:17, Viktor Dukhovni wrote:

On Wed, Sep 14, 2016 at 10:27:32AM +0200, Antoine Nguyen wrote:


Do make sure that your tests with the sql CLI really make the same
query against the same database:

 SELECT name FROM admin_domain WHERE name='' AND 
type='domain' AND enabled=1


I've enabled queries logging. Here is the result :

160914  8:24:14   57 QuerySELECT name FROM admin_domain WHERE 
name='gaël.com' AND type='domain' AND enabled=1
160914  8:24:31   60 Connectmodoboa@localhost as anonymous on modoboa
   60 QuerySELECT name FROM admin_domain WHERE 
name='gaël.com' AND type='domain' AND enabled=1
   60 Quit

The first query was executed using mysql shell and it returns 1 row. The
second query was executed by postmap and returns nothing whereas we can see
they are the same...

Do post the "Connect" string for *both* queries.


Here is the missing line :

160914  8:23:5757 Connect   root@localhost as anonymous on modoboa

I indeed tried with root but result is the same if I use modoboa user 
with mysql shell: it works.


Antoine

Re: After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

[Viktor Dukhovni]

On Wed, Sep 14, 2016 at 01:11:53PM +0100, Dominic Raferd wrote:

> I am using Postfix 3.1.0 and following instructions at
> http://www.postfix.org/TLS_README.html#client_smtps to set up for sending
> some (recipient dependent) emails via smtps (whereas others go over TLS to
> a different relay server).

Otherwise also called "TLS wrapper mode" in which a TLS handshake
takes place immediately after the TCP 3-way hanshake, and the SMTP
session runs inside TLS.  Note that:

smtp_tls_wrappermode = yes

is a global setting for the transport, that is, it depends only
on the transport used, not the nexthop domain.

>  So when it fails, Postfix falls back using the hosts
> specified in main.cf's smtp_fallback_relay (*not* relayhost, which is used
> for emails that don't have a match in the transport list).

It does not matter whether "smtp_fallback_relay" is in main.cf or
in master.cf specified per transport.   Either way, the fallback
delivery always uses the same transport agent used for the primary
nexthop.  Which means that smtp_fallback_relay will use smtps,
when the primary nexthop uses smtps.  This does not depend on
the nexthop destination's port number.

What you're looking for is a new feature, in which wrapper mode is
enabled conditionally, only when the port is 465, and not when it
is some other port.  That code has not been written.

It is hard to imagine why an MSA on port 465 would implement quotas.
Generally, port 465 MSAs just do outbound submission, and not
inbound mailbox delivery.  Is there some provider that's mixing
up these services?  Is this configuration self-inflicted?

If the primary MSA provider also supports STARTTLS on port 587,
use that instead, and don't enable TLS wrapper mode.

-- 
Viktor.

Re: mysql lookup table and utf8

[Viktor Dukhovni]

On Wed, Sep 14, 2016 at 10:27:32AM +0200, Antoine Nguyen wrote:

> >Do make sure that your tests with the sql CLI really make the same
> >query against the same database:
> >
> > SELECT name FROM admin_domain WHERE name='' AND 
> > type='domain' AND enabled=1
> >
> I've enabled queries logging. Here is the result :
> 
> 160914  8:24:14   57 QuerySELECT name FROM admin_domain WHERE 
> name='gaël.com' AND type='domain' AND enabled=1
> 160914  8:24:31   60 Connectmodoboa@localhost as anonymous on modoboa
>   60 QuerySELECT name FROM admin_domain WHERE 
> name='gaël.com' AND type='domain' AND enabled=1
>   60 Quit
> 
> The first query was executed using mysql shell and it returns 1 row. The
> second query was executed by postmap and returns nothing whereas we can see
> they are the same...

Do post the "Connect" string for *both* queries. 

-- 
Viktor.

After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

[Dominic Raferd]

I am using Postfix 3.1.0 and following instructions at
http://www.postfix.org/TLS_README.html#client_smtps to set up for sending
some (recipient dependent) emails via smtps (whereas others go over TLS to
a different relay server). This uses the transport_maps settings in main.cf,
a transport file (hashed) and special routing (relay-smtps) in master.cf.

This works - when the onward smtps server accepts the emails. However in my
case this doesn't always happen -  basically they sometimes block when we
are over quota. So when it fails, Postfix falls back using the hosts
specified in main.cf's smtp_fallback_relay (*not* relayhost, which is used
for emails that don't have a match in the transport list).

All well and good. But I find that after smtps rejection, the
fallback_relay hosts (both) always fail too with message like:

warning: TLS library problem: error:140770FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:

With effect that the email cannot be sent at all.

In short like this:
/etc/postfix/main.cf
transport_maps = hash:/etc/postfix/transport
relayhost = [smtp.send.net]
smtp_fallback_relay = [relay.grad.net] [smtp.send.net]

/etc/postfix/transport and /etc/postfix/main.cf - as specified at
http://www.postfix.org/TLS_README.html#client_smtps for Postfix >= 3.0

However if I remove the initial attempt to use smtps (i.e. comment out
transport_maps and reload postfix), then relayhost and fallback_relays work
perfectly.

I've tried a raft of different settings without success. Any suggestions
gratefully received.

Dominic

Re: convert all incoming files from postfix

[Eero Volotinen]

2016-09-14 14:42 GMT+03:00 Darac Marjal :

> On Wed, Sep 14, 2016 at 10:46:06AM +0300, Eero Volotinen wrote:
>
>> Hi List,
>>
>> Is there utility/tool to convert incoming emails to text and convert
>> attachments to pdf/a format?
>>
>
> It looks like Mimedefang should be able to do this, but you'll need to
> know how to write some perl.
>
> A devil's advocate question for you to consider: How would you handle an
> audio or video attachment?
>
>
I just delete other types than pdf ? :) In this usage video and audio
attachments are not needed.

Eero

Re: Message size limit responses

[JosC]

In een bericht van 14-9-2016 5:11:


By "message" do you mean an actual piece of email reporting the problem
or a notification in the Thunderbird user interface?


I mean indeed by Thunderbird.


Email messages reporting a delivery failure are almost always generated
by some MTA, e.g. Postfix. There's a standard format for such failure
report messages that most MTAs use which includes an explicit
"Reporting-MTA" field identifying the generator of the report.

A "message" from the TBird UI (i.e. an alert window or error message in
a status area of the main widow, etc.) is almost certainly generated by
TBird itself. The first step in submitting a message is the MUA (TBird)
saying "EHLO " to the MSA/MTA (Postfix) and getting a response
listing the supported extensions to SMTP supported by that server. Example:


Thanks for your exented info on this.


passed along from that external program. For example, I use code run via
the MIMEDefang milter to impose smaller limits on some sender/recipient
combinations which can reply with text saying the message is too large.
In that case, Postfix is sending an explicit rejection response to the
client and it is up to the client to relay that back to the user.


So I need to install the MIMEDefang milter to get what I want or do I 
misunderstand you?


Cheers,
Jos Chrispijn

Re: mysql lookup table and utf8

[Antoine Nguyen]

On 14/09/2016 12:53, Wietse Venema wrote:

Antoine Nguyen:
[ Charset windows-1252 converted... ]

On 14/09/2016 10:27, Antoine Nguyen wrote:

The first query was executed using mysql shell and it returns 1 row.
The second query was executed by postmap and returns nothing whereas
we can see they are the same...


I've just tried with postgresql and the result is the same...

I forgot, did the same query work for a non-UTF8 domain name?



Yes, it works.

Antoine

Re: mysql lookup table and utf8

[Wietse Venema]

Antoine Nguyen:
[ Charset windows-1252 converted... ]
> On 14/09/2016 10:27, Antoine Nguyen wrote:
> > The first query was executed using mysql shell and it returns 1 row. 
> > The second query was executed by postmap and returns nothing whereas 
> > we can see they are the same...
> >
> I've just tried with postgresql and the result is the same...

I forgot, did the same query work for a non-UTF8 domain name?

Wietse

Creating a catch all domain

[Angel L. Mateo]

Hi,

	I'm obfuscated trying to configure a server for a catch-all domain (all 
mail directed to that domain delivered to a single mailbox).


	My problem is that I want all mail received for @mydomain.com to be 
delivered to a single locally mailbox, but r...@mydomain.com to be 
relayed to the actual @mydomain.com server.


	I have configured a virtual domain, but is the last condition what I 
don't know how to configure it.


Any help?

--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868889150
Fax: 86337

Re: mysql lookup table and utf8

[Antoine Nguyen]

On 14/09/2016 10:27, Antoine Nguyen wrote:
The first query was executed using mysql shell and it returns 1 row. 
The second query was executed by postmap and returns nothing whereas 
we can see they are the same...



I've just tried with postgresql and the result is the same...

Antoine

Re: mysql lookup table and utf8

[Antoine Nguyen]

On 14/09/2016 04:01, Viktor Dukhovni wrote:

On Tue, Sep 13, 2016 at 09:52:16PM +0200, Antoine Nguyen wrote:


query = SELECT name FROM admin_domain WHERE name='%s' AND type='domain' AND 
enabled=1

What is not clear is how MySQL's quoting behaves given the input
UTF-8 string.


postmap: cfg_get_str: /etc/postfix/sql-domains.cf: query = SELECT name FROM 
admin_domain WHERE name='%s' AND type='domain' AND enabled=1

postmap: dict_mysql: successful query from host 127.0.0.1

postmap: dict_mysql_lookup: retrieved 0 rows

I was hoping to see the expanded query string, but it is not output
with "-v".  Perhaps there's some sort of logging you can enable in
the MySQL server or client libraries.

Do make sure that your tests with the sql CLI really make the same
query against the same database:

 SELECT name FROM admin_domain WHERE name='' AND 
type='domain' AND enabled=1


I've enabled queries logging. Here is the result :

160914  8:24:14   57 QuerySELECT name FROM admin_domain WHERE 
name='gaël.com' AND type='domain' AND enabled=1

160914  8:24:31   60 Connectmodoboa@localhost as anonymous on modoboa

  60 QuerySELECT name FROM admin_domain WHERE 
name='gaël.com' AND type='domain' AND enabled=1

  60 Quit

The first query was executed using mysql shell and it returns 1 row. The 
second query was executed by postmap and returns nothing whereas we can 
see they are the same...


Antoine

convert all incoming files from postfix

[Eero Volotinen]

Hi List,

Is there utility/tool to convert incoming emails to text and convert
attachments to pdf/a format?

Eero

Re: Feature request for postscreen: "defer"

[Christian Rößner]

> Am 14.09.2016 um 07:50 schrieb Christian Rößner 
> :
> 
>> Am 13.09.2016 um 19:00 schrieb Wietse Venema :
>> 
>> Christian Ro??ner:
 Am 13.09.2016 um 18:09 schrieb Wietse Venema :
 
 Christian Ro??ner:
> Is there some chance that postscreen could be extended to also have 
> "defer"?
 
 That is a good question, but you might want to ask that in a thread
 that isn't about socketmaps.
>>> 
>>> You are totally right. I created a new thread for this.
>>> 
>>> The idea is to give postscreen a "defer" option. At connect time,
>>> dynamic services can work with the IP address of a connecting
>>> client. In some cases, this can result in whitelisting, blacklisting
>>> or no decision. But a fourth decision: "defer" might be interesting
>>> in cases, where the risk of a false-positive decision is too big.
>>> 
>>> Having this in postscreen reduces load on external DNS queries,
>>> if you also use dnsblog.
>> 
>> Unlike DNS lookups, the access map lookup is a blocking operation,
>> and if your tcp map takes 80ms to complete (a typical trans-atlantic
>> query), then you can handle only 12 connections per second, and
>> make postsceen the largest performance bottleneck on the system.
> 
> Good point. I will think about moving the tcp-map to "smtpd".
> 
> Thank you very much for clarifying the performance impact

Ah... Just read about the postscreen-policy idea. :-)
-- 
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com




smime.p7s
Description: S/MIME cryptographic signature