Re: Dumping effective postfix configuration

[Wietse Venema]

Viktor Dukhovni:
> > The Postfix master creates as many sockets as needed for an inet
> > service, and sets the socket option SO_REUSEADDR on each socket,
> > and bind()s them to the desired addresses.
> > 
> > With that, it may be possible for the Postfix master to create new
> > sockets, set SO_REUSEADDR on each socket, and bind() them to the
> > new addresses; if successful, close() the old sockets, otherwise
> > close() the new sockets.
> 
> Yes, typically doable, by determining which bindings are unchanged,
> which new, and which old.
> 
> > Am I missing something? This will have to work on all supported
> > systems, though. Not just Linux, not just *BSD.
> 
> The tricky case is changing a wildcard binding to a set of non-wildcard
> bindings.  When a wildcard binding is active, it is AFAIK not generally
> possible to bind non-wildcard listeners for the same port, and
> presumably the converse.
> 
> Changes in explicit lists of IPs should be viable as you noted.

The configurations of interest are:

inet_interfaces = all (wildcard binding)
inet_interfaces = enumeration (non-wildcard binding)

Changes of type wildcard->wildcard are noops.

Changes of type enumeration->enumeration are partial noops if one
only touches the sockets whose addresses have changed.

That leaves wildcard->enumeration and enumeration->wildcard.  Both
*should* be safe on BSD-ish (and Solaris, HP-UX) systems, given how
SO_REUSEADDR was originally implemented. See the "BSD SO_REUSEADDR"
discussion with a nice table in:
https://stackoverflow.com/questions/14388706/how-do-so-reuseaddr-and-so-reuseport-differ
This also comes with a nice test program.

With Linux the changes of type wildcard->enum and enum->wildcard
require code that is kernel version dependent.  If we consider only
kernels >= 3.9 then we can keep it simple with SO_REUSEPORT.

All of this needs to be evaluated not only on an idle server where
'listen' sockets are open only in the master, but also with child
process that hold a reference to a master's listen socket as well
as connected sockets. And then it needs to deal with sockets that
are in the TIME_WAIT state.

Wietse

Re: Dumping effective postfix configuration

[Wietse Venema]

Demi Marie Obenour:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> On 1/6/23 07:15, Wietse Venema wrote:
> > Peter Wienemann:
> >> Hi,
> >>
> >> is there a way to dump the effective postfix configuration rather than 
> >> the one specified in main.cf/master.cf? It seems that changes to 
> >> main.cf/master.cf have an immediate impact on the output of postconf 
> >> regardless of whether a reload/restart of the service was performed.
> > 
> > How would that work? Different Postfix processes start at different
> > times, and some processes (qmgr, master) run forever.
> 
> What about using inotify/kqueue to determine when a config file has
> changed and reload accordingly?

It is not necessarily desirable that a daemon refreshes as soon as
one file has changed, especially when multiple files need to be
updated. I think that it is not burdensome to "postfix reload".

kqueue and inotify were introduced to BSD and Linux years after
Postfix was already released. They have no equivalent on other
systems, and MacOS kqueue has a problematic history with Postfix.

Wietse

Re: Dumping effective postfix configuration

[Viktor Dukhovni]

On Fri, Jan 06, 2023 at 03:28:23PM -0500, Wietse Venema wrote:

> > The documentation of inet_interfaces says otherwise, my recollection is
> > that master(8) does not attempt to rebind inet sockets on "reload":
> 
> I see. Yes, that could be dififcult. Or maybe not. 
> 
> The Postfix master creates as many sockets as needed for an inet
> service, and sets the socket option SO_REUSEADDR on each socket,
> and bind()s them to the desired addresses.
> 
> With that, it may be possible for the Postfix master to create new
> sockets, set SO_REUSEADDR on each socket, and bind() them to the
> new addresses; if successful, close() the old sockets, otherwise
> close() the new sockets.

Yes, typically doable, by determining which bindings are unchanged,
which new, and which old.

> Am I missing something? This will have to work on all supported
> systems, though. Not just Linux, not just *BSD.

The tricky case is changing a wildcard binding to a set of non-wildcard
bindings.  When a wildcard binding is active, it is AFAIK not generally
possible to bind non-wildcard listeners for the same port, and
presumably the converse.

Changes in explicit lists of IPs should be viable as you noted.

-- 
Viktor.

Re: Dumping effective postfix configuration

[Emmanuel Fusté]

Le 06/01/2023 à 21:03, Demi Marie Obenour a écrit :

On 1/6/23 07:15, Wietse Venema wrote:

Peter Wienemann:

Hi,

is there a way to dump the effective postfix configuration rather than
the one specified in main.cf/master.cf? It seems that changes to
main.cf/master.cf have an immediate impact on the output of postconf
regardless of whether a reload/restart of the service was performed.

How would that work? Different Postfix processes start at different
times, and some processes (qmgr, master) run forever.

What about using inotify/kqueue to determine when a config file has
changed and reload accordingly?

Too dangerous and useless.
I want to issue reload for long running processes only when I want.
Periodically recycled process will take automatically the new conf when 
they restarts, inotify/kqueue is not needed for that. That is something 
you must know as a postfix user to not inadvertently crash your running 
config with half edited but saved config files.

Same expectations and warning for maps (according to their type).
For the conf files, one interesting change would be to do the opposite : 
Process only run with copies of validated conf files and new copies (+ 
process reload) are done only when explicit reload command is issued to 
avoid new conf taken by surprise on process recycling.


Emmanuel.

Re: Dumping effective postfix configuration

[Wietse Venema]

Viktor Dukhovni:
> On Fri, Jan 06, 2023 at 01:45:48PM -0500, Wietse Venema wrote:
> 
> > > Most changes in main.cf require a reload to become effective but there 
> > > are some exceptions requiring a restart, e. g. a change of 
> > > inet_interfaces. 
> > 
> > That is incorrect. If inet_interfaces is changed, then a "postfix
> > reload" (not restart) is required because the master daemon is a
> > long-running process.
> 
> The documentation of inet_interfaces says otherwise, my recollection is
> that master(8) does not attempt to rebind inet sockets on "reload":

I see. Yes, that could be dififcult. Or maybe not. 

The Postfix master creates as many sockets as needed for an inet
service, and sets the socket option SO_REUSEADDR on each socket,
and bind()s them to the desired addresses.

With that, it may be possible for the Postfix master to create new
sockets, set SO_REUSEADDR on each socket, and bind() them to the
new addresses; if successful, close() the old sockets, otherwise
close() the new sockets.

Am I missing something? This will have to work on all supported
systems, though. Not just Linux, not just *BSD.

Wietse

Re: Dumping effective postfix configuration

[Demi Marie Obenour]

On 1/6/23 07:15, Wietse Venema wrote:
> Peter Wienemann:
>> Hi,
>>
>> is there a way to dump the effective postfix configuration rather than 
>> the one specified in main.cf/master.cf? It seems that changes to 
>> main.cf/master.cf have an immediate impact on the output of postconf 
>> regardless of whether a reload/restart of the service was performed.
> 
> How would that work? Different Postfix processes start at different
> times, and some processes (qmgr, master) run forever.

What about using inotify/kqueue to determine when a config file has
changed and reload accordingly?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Dumping effective postfix configuration

[Peter Wienemann]

On 06.01.23 20:02, Viktor Dukhovni wrote:

On Fri, Jan 06, 2023 at 01:45:48PM -0500, Wietse Venema wrote:


Most changes in main.cf require a reload to become effective but there
are some exceptions requiring a restart, e. g. a change of
inet_interfaces.


That is incorrect. If inet_interfaces is changed, then a "postfix
reload" (not restart) is required because the master daemon is a
long-running process.


The documentation of inet_interfaces says otherwise, my recollection is
that master(8) does not attempt to rebind inet sockets on "reload":

 src/master/master_ent.c: /*
 src/master/master_ent.c:  * XXX We cannot change the inet_interfaces 
setting for a running master
 src/master/master_ent.c:  * process. Listening sockets are inherited by 
child processes so that
 src/master/master_ent.c:  * closing and reopening those sockets in the 
master does not work.
 src/master/master_ent.c:  *
 src/master/master_ent.c:  * Another problem is that library routines still 
cache results that are
 src/master/master_ent.c:  * based on the old inet_interfaces setting. It 
is too much trouble to
 src/master/master_ent.c:  * recompute everything.
 src/master/master_ent.c:  *
 src/master/master_ent.c:  * In order to keep our data structures 
consistent we ignore changes in
 src/master/master_ent.c:  * inet_interfaces settings, and issue a warning 
instead.
 src/master/master_ent.c:  */

If one really wants to change the IP address and/or number of listen
endpoints, a restart is required.


This also matches the warnings in the logs. After a reload following a 
change of inet_interfaces the logs contain the following warning:


---
postfix/master[58283]: reload -- version 3.5.17, configuration /etc/postfix
postfix/master[58283]: warning: service smtp: ignoring inet_interfaces 
change
postfix/master[58283]: warning: to change inet_interfaces, stop and 
start Postfix

---

Peter

Re: Dumping effective postfix configuration

[Viktor Dukhovni]

On Fri, Jan 06, 2023 at 01:45:48PM -0500, Wietse Venema wrote:

> > Most changes in main.cf require a reload to become effective but there 
> > are some exceptions requiring a restart, e. g. a change of 
> > inet_interfaces. 
> 
> That is incorrect. If inet_interfaces is changed, then a "postfix
> reload" (not restart) is required because the master daemon is a
> long-running process.

The documentation of inet_interfaces says otherwise, my recollection is
that master(8) does not attempt to rebind inet sockets on "reload":

src/master/master_ent.c: /*
src/master/master_ent.c:  * XXX We cannot change the inet_interfaces 
setting for a running master
src/master/master_ent.c:  * process. Listening sockets are inherited by 
child processes so that
src/master/master_ent.c:  * closing and reopening those sockets in the 
master does not work.
src/master/master_ent.c:  *
src/master/master_ent.c:  * Another problem is that library routines still 
cache results that are
src/master/master_ent.c:  * based on the old inet_interfaces setting. It is 
too much trouble to
src/master/master_ent.c:  * recompute everything.
src/master/master_ent.c:  *
src/master/master_ent.c:  * In order to keep our data structures consistent 
we ignore changes in
src/master/master_ent.c:  * inet_interfaces settings, and issue a warning 
instead.
src/master/master_ent.c:  */

If one really wants to change the IP address and/or number of listen
endpoints, a restart is required.

-- 
Viktor.

Re: Dumping effective postfix configuration

[Wietse Venema]

Peter Wienemann:
> Most changes in main.cf require a reload to become effective but there 
> are some exceptions requiring a restart, e. g. a change of 
> inet_interfaces. 

That is incorrect. If inet_interfaces is changed, then a "postfix
reload" (not restart) is required because the master daemon is a
long-running process.

Similar considerations apply when changes are made that affect the
queue mamager process (for example, changes that affect concurrency
management).

Other Postfix processes have a finite life time, and will eventually
pick up configuration changes. If you can't wait, then use "postfix
reload".

Wietse

Re: Dumping effective postfix configuration

[Viktor Dukhovni]

On Fri, Jan 06, 2023 at 06:42:18PM +0100, Peter Wienemann wrote:

> Most changes in main.cf require a reload to become effective

No. In most cases they merely require the passage of time, and typical
changes are not that time-sensitive.

> I am trying to put main.cf under configuration 
> management and have to trigger an action each time main.cf changes such 
> that the changes become effective.

If you make changes to main.cf that are time-sensitive, push a separate
file whose update will cause a reload.  If your changes require a
restart, push a separate file whose update triggers a restart.  Most of
the time leave both sentinel files alone.

> At the moment I always perform a restart after a change of main.cf
> (just to be on the safe side).

This is not necessary in most cases, and should be avoided if possible.

> But on a busy mail server this is not ideal. I am looking for a way to
> do better. One idea that came to my mind is:

Reloads are also not ideal.

> 1. Initially try a reload and check whether the effective configuration 
> is different from the target configuration as specified in main.cf.
> 
> 2. If both match, we are done. If there is a discrepancy, launch a restart.

You're over-engineering the problem.  Let the operator who authors the
change decide whether a restart or reload is required, or whether just
normal Postfix process recycling is sufficient for your needs.

On a busy server, you can reduce max_idle and or max_use to recycle
processes more often:

max_idle = 3s
max_use = 20

Most smtpd(8) processes and delivery agents would last not much longer
than a minute before they exit and are replaced.  The additional cost
of process creation will be modest.

-- 
Viktor.

Re: Dumping effective postfix configuration

[Peter Wienemann]

On 06.01.23 17:33, Wietse Venema wrote:

Peter Wienemann:

On 06.01.23 13:15, Wietse Venema wrote:

is there a way to dump the effective postfix configuration rather than
the one specified in main.cf/master.cf? It seems that changes to
main.cf/master.cf have an immediate impact on the output of postconf
regardless of whether a reload/restart of the service was performed.


How would that work? Different Postfix processes start at different
times, and some processes (qmgr, master) run forever.


I could think of something like this:

Instead of sending a HUP signal like it is done to trigger a reload, one
sends a different signal (e. g. USR1) to the master. The further
processing of the signal is similar to the HUP case except that
configuration dumps are triggered rather than configuration reloads.


How could that be useful? On a busy server, there will be be 100+
smtpd (SMTP server) processes, 100+ cleanup processes, 100+ smtp
(SMTP client) processes and so on. Those processes were started an
different times and they will produce different dumps if you change
Postfix configuration without "postfix reload".

If you want an accurate picture of what configuration is in effect.
then I think that is not too much trouble to run "postfix reload"
after a configuration change. Then "postconf" output reflects the
effective configuration.

Instead of dumping configurations, there are other ways. For example,
each daemon could log configuration file stamps when the process
is started (or communicate that info in some other manner). Given
a history of (time stamp, config file content) you could use the
logged time stamps to find out what configuration is (or was) in
effect for each daemon process.


I am trying to solve the following problem:

Most changes in main.cf require a reload to become effective but there 
are some exceptions requiring a restart, e. g. a change of 
inet_interfaces. I am trying to put main.cf under configuration 
management and have to trigger an action each time main.cf changes such 
that the changes become effective. At the moment I always perform a 
restart after a change of main.cf (just to be on the safe side). But on 
a busy mail server this is not ideal. I am looking for a way to do 
better. One idea that came to my mind is:


1. Initially try a reload and check whether the effective configuration 
is different from the target configuration as specified in main.cf.


2. If both match, we are done. If there is a discrepancy, launch a restart.

That is how I ended up with my initial question. Maybe there are 
better/simpler ways to accomplish the desired result. Suggestions are 
welcome.


Peter

Re: Dumping effective postfix configuration

[Viktor Dukhovni]

On Fri, Jan 06, 2023 at 11:33:28AM -0500, Wietse Venema wrote:

> > Instead of sending a HUP signal like it is done to trigger a reload, one 
> > sends a different signal (e. g. USR1) to the master. The further 
> > processing of the signal is similar to the HUP case except that 
> > configuration dumps are triggered rather than configuration reloads.
> 
> How could that be useful? On a busy server, there will be be 100+
> smtpd (SMTP server) processes, 100+ cleanup processes, 100+ smtp
> (SMTP client) processes and so on. Those processes were started an
> different times and they will produce different dumps if you change
> Postfix configuration without "postfix reload".

+1.  It makes little sense to ask a distributed (over multiple
dynamically spawned processes) system about its "current" state.

The age in seconds of master and its descendants can be obtained via,
for example:

$ ps -c -o etimes= -o pid= -o command= -p $(pgrep -g $(ps -o pgid= $(pgrep 
-x master))) | sort -nr
2466115 87674 master
 384351 70993 qmgr
 384315 71008 tlsmgr
   2402 39744 pickup
368 39967 anvil
368 39965 smtpd
 52 40089 proxymap
 52 40088 smtpd
 14 40098 smtpd
 12 40099 trivial-rewrite

Even fancier, splice in the age the main.cf and master.cf files:

$ (
ps -c -o etimes= -o pid= -o command= -p $(pgrep -g $(ps -o pgid= $(pgrep -x 
master)))
perl -le '
use File::stat;
for (@ARGV) {printf "%d - %s\n", time - stat($_)->mtime, $_}
' /usr/local/etc/postfix/ma*.cf
  ) | awk '{printf "%10s %10s %s\n", $1, $2, $3}' | sort -nr
  28755246  - /usr/local/etc/postfix/master.cf
   2467086  87674 master
385324  - /usr/local/etc/postfix/main.cf
385322  70993 qmgr
385286  71008 tlsmgr
  3373  39744 pickup
 1  40259 anvil
 1  40258 proxymap
 1  40257 smtpd
 0  40260 trivial-rewrite

The master(8) process is younger than master.cf and the rest are younger
than main.cf, so all is well, assuming that no critical changes
affecting master(8) were made in main.cf (inet_interfaces, ...).

-- 
Viktor.

Re: Dumping effective postfix configuration

[Wietse Venema]

Peter Wienemann:
> On 06.01.23 13:15, Wietse Venema wrote:
> >> is there a way to dump the effective postfix configuration rather than
> >> the one specified in main.cf/master.cf? It seems that changes to
> >> main.cf/master.cf have an immediate impact on the output of postconf
> >> regardless of whether a reload/restart of the service was performed.
> > 
> > How would that work? Different Postfix processes start at different
> > times, and some processes (qmgr, master) run forever.
> 
> I could think of something like this:
> 
> Instead of sending a HUP signal like it is done to trigger a reload, one 
> sends a different signal (e. g. USR1) to the master. The further 
> processing of the signal is similar to the HUP case except that 
> configuration dumps are triggered rather than configuration reloads.

How could that be useful? On a busy server, there will be be 100+
smtpd (SMTP server) processes, 100+ cleanup processes, 100+ smtp
(SMTP client) processes and so on. Those processes were started an
different times and they will produce different dumps if you change
Postfix configuration without "postfix reload".

If you want an accurate picture of what configuration is in effect.
then I think that is not too much trouble to run "postfix reload"
after a configuration change. Then "postconf" output reflects the
effective configuration.

Instead of dumping configurations, there are other ways. For example,
each daemon could log configuration file stamps when the process
is started (or communicate that info in some other manner). Given
a history of (time stamp, config file content) you could use the
logged time stamps to find out what configuration is (or was) in
effect for each daemon process.

Wietse

Re: Dumping effective postfix configuration

[Peter Wienemann]

On 06.01.23 13:15, Wietse Venema wrote:

is there a way to dump the effective postfix configuration rather than
the one specified in main.cf/master.cf? It seems that changes to
main.cf/master.cf have an immediate impact on the output of postconf
regardless of whether a reload/restart of the service was performed.


How would that work? Different Postfix processes start at different
times, and some processes (qmgr, master) run forever.


I could think of something like this:

Instead of sending a HUP signal like it is done to trigger a reload, one 
sends a different signal (e. g. USR1) to the master. The further 
processing of the signal is similar to the HUP case except that 
configuration dumps are triggered rather than configuration reloads.


What I have in mind would be a similar user experience to what one gets 
when running "ceph config show [...]" [0] in the Ceph case or 
"condor_config_val [daemon]" [1] in case of HTCondor.


Peter

[0] https://docs.ceph.com/en/latest/rados/configuration/ceph-conf/#commands

[1] 
https://htcondor.readthedocs.io/en/latest/man-pages/condor_config_val.html

Re: Dumping effective postfix configuration

[Wietse Venema]

Peter Wienemann:
> Hi,
> 
> is there a way to dump the effective postfix configuration rather than 
> the one specified in main.cf/master.cf? It seems that changes to 
> main.cf/master.cf have an immediate impact on the output of postconf 
> regardless of whether a reload/restart of the service was performed.

How would that work? Different Postfix processes start at different
times, and some processes (qmgr, master) run forever.

Wietse

Dumping effective postfix configuration

[Peter Wienemann]

Hi,

is there a way to dump the effective postfix configuration rather than 
the one specified in main.cf/master.cf? It seems that changes to 
main.cf/master.cf have an immediate impact on the output of postconf 
regardless of whether a reload/restart of the service was performed.


Peter

Re: Postfix Configuration from an Exim background

[Viktor Dukhovni]

On Thu, Dec 08, 2022 at 01:16:34PM -0600, Scott Mutter wrote:

> I'm just beginning to look at Postfix configurations (at a very leisurely
> pace I might add).

You reall should read the Postfix book by Ralf and Patrick, despite its
age, it substantially applies to all Postfix releases since.

The relevant project tutorials are:

https://www.postfix.org/OVERVIEW.html#receiving
https://www.postfix.org/SMTPD_ACCESS_README.html
https://www.postfix.org/access.5.html
http://www.postfix.org/CONTENT_INSPECTION_README.html

-- 
Viktor.

Re: Postfix Configuration from an Exim background

[Jaroslaw Rafa]

Dnia  8.12.2022 o godz. 13:16:34 Scott Mutter pisze:
> In an SMTP transaction there are certain commands that pertain to certain
> areas of the SMTP message, specifically:
> 
> MAIL FROM
> RCPT TO
> DATA
> 
> In Exim, there is an ACL configuration block - acl_smtp_mail - that can be
> used to parse the information presented in the MAIL FROM command and this
> determines if the connection should be allowed to proceed.

smtpd_sender_restrictions=

> Likewise, there is an ACL configuration block - acl_smtp_rcpt - that parses
> the information from the RCPT TO command and determines how to proceed
> along the connection.

smtpd_relay_restrictions= 
and
smtpd_recipient_restrictions=

> And the ACL Configuration block - acl_smtp_data - that can parse the
> information presented after the DATA command to determine how to proceed
> with the connection.

smtpd_end_of_data_restrictions=

However to parse the actual *content* given in the DATA command you should
rather use milters.

> Are there any equivalent such configuration blocks with Postfix?  Or how
> would one go about processing information given from these commands?

In addition to the above, there are also:

smtpd_client_restrictions= - applied just at the start of connection, where
Postfix knows only the connecting client's IP address

smtpd_helo_restrictions= - applied in the HELO/EHLO phase

smtpd_data_restrictions= - applied at the BEGINNING of the DATA command (not
AFTER the DATA command)
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Postfix Configuration from an Exim background

[Matus UHLAR - fantomas]

On 08.12.22 13:16, Scott Mutter wrote:

In Exim, there is an ACL configuration block - acl_smtp_mail - that can be
used to parse the information presented in the MAIL FROM command and this
determines if the connection should be allowed to proceed.

Likewise, there is an ACL configuration block - acl_smtp_rcpt - that parses
the information from the RCPT TO command and determines how to proceed
along the connection.

And the ACL Configuration block - acl_smtp_data - that can parse the
information presented after the DATA command to determine how to proceed
with the connection.

Are there any equivalent such configuration blocks with Postfix?  Or how
would one go about processing information given from these commands?


postfix has restrictions like:

http://www.postfix.org/postconf.5.html#smtpd_sender_restrictions
http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions
http://www.postfix.org/postconf.5.html#smtpd_end_of_data_restrictions

ane many other, see:

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

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]

Postfix Configuration from an Exim background

[Scott Mutter]

I'm just beginning to look at Postfix configurations (at a very leisurely
pace I might add).

I come from a mostly Exim background, so the configuration of Postfix is
really somewhat foreign to me.

In an SMTP transaction there are certain commands that pertain to certain
areas of the SMTP message, specifically:

MAIL FROM
RCPT TO
DATA

In Exim, there is an ACL configuration block - acl_smtp_mail - that can be
used to parse the information presented in the MAIL FROM command and this
determines if the connection should be allowed to proceed.

Likewise, there is an ACL configuration block - acl_smtp_rcpt - that parses
the information from the RCPT TO command and determines how to proceed
along the connection.

And the ACL Configuration block - acl_smtp_data - that can parse the
information presented after the DATA command to determine how to proceed
with the connection.

Are there any equivalent such configuration blocks with Postfix?  Or how
would one go about processing information given from these commands?

Re: Solving reverse DNS problem with Postfix configuration?

[Paul van der Vlis]

Hi Richard,

Op 12-04-2022 om 14:07 schreef Richard Rasker:


Op 11-04-22 om 18:34 schreef Paul van der Vlis:

Hi Richard, ...


Eventually you could use my mailserver as a relayhost. 


That is a very friendly offer, but if I do, that would of course only 
be temporary, so that I can send e-mail again, and I'd contact you in 
advance.


You need a username and password.


That's of course why I would contact you first :-)

But according to the information supplied, I should also be able to use 
smtp.xs4all.nl as a relay host, see 
https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already took 
care of the Spamhaus delisting).


Question: does this solve the PTR record problem?


I don't think so, but I did not study it really well.

Just to make sure: I guess I need to change my MX record for this to 
work? 


For sending e-mail, you don't need to change the MX record.


And how does reverse DNS work in this case? Sorry if I ask beginners' 
questions, but as I said, I never had to get into these details of mail 
servers and anti-spam measures -- up until yesterday, it 'Just Worked'.


You use the DNS & rDNS of the relayhost.

(And unfortunately, switching to freedom.nl as a new ISP has one 
drawback wrt. VOIP -- I can only keep one of our current two phone lines.)


Freedom.nl does not have an own VOIP service, the buy it from Voys.
I did make a contract direct there: https://www.voys.nl/
I pay 19 euro a month, but calling in the Netherlands is free.

And I use this for extra phone numbers:
https://www.cheapconnect.nl/voip-nummer-kopen/
Costs is about 9 euro a year for an extra phone number.

I use this for phone calls to other countries:
https://www.intervoip.com/calling_rates/
You can configure the Fritzbox or something like that to do that 
automatically, while the other side sees your normal phone number as 
caller ID.


With regards,
Paul




--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Solving reverse DNS problem with Postfix configuration?

[Jaroslaw Rafa]

Dnia 12.04.2022 o godz. 15:03:40 Richard Rasker pisze:
> 
> Sorry, I wasn't being clear here. What I mean to ask is if (and how)
> using a mail relay for sending mail could solve the problem that at
> the receiving end, reverse DNS does not match the originating
> domain.

Reverse DNS doesn't have to match the originating domain. But it has to be
consistent (ie. IP address -> PTR name -> the same IP address) and it has to
be "non-generic", ie. "smtp.xs4all.nl" is good, while
"195-121-65-191.dc.kpn.net" is not, as it seems too generic and many
mailservers will reject such name. (Also, as someone noted, IP address
195.121.65.191 is included in SORBS Dynamic IP Addresses blacklist, so mail
from this address will be rejected by most systems anyway)

If the mail relay's *outgoing* IP address (note: we don't know the actual
*outgoing* IP address that smtp.xs4all.nl uses, we know only the incoming
address used to submit mail) has a non-generic and properly resolving PTR
hostname, using a relay should solve your problem.

However, while mail relay's PTR name doesn't have to match the originating
domain, its IP address (the outgoing one) should be included in SPF record
for the originating domain, if you do use SPF.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Op 12-04-22 om 14:20 schreef Jaroslaw Rafa:

Dnia 12.04.2022 o godz. 14:07:13 Richard Rasker pisze:

But according to the information supplied, I should also be able to
use smtp.xs4all.nl as a relay host, see
https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already
took care of the Spamhaus delisting).

Question: does this solve the PTR record problem?

Probably not, because smtp.xs4all.nl has IP address 195.121.65.191, and
reverse DNS for 195.121.65.191 is 195-121-65-191.dc.kpn.net. So it is also a
"generic" hostname which may cause some systems to reject mail sent from
this address. The ISP has configured it wrong; 195.121.65.191 should resolve
back to smtp.xs4all.nl.


Yes, I figured as much already ... Bit of a shame, really, because 
originally, XS4All used to be one of the very best ISP's worldwide, in 
regard to both technology as well as customer choice and customer 
service -- and I happily paid their rather steep subscription fees in 
order to have full control over what I could and couldn't do with my 
Internet connection.


After being taken over by KPN, all this seems to have gone down the 
drain, with only the high cost remaining. Apparently, this ISP doesn't 
want any 'difficult' customers doing things such as running their own 
servers and the likes.



For sending e-mail, you don't need to change the MX record.

And how does reverse DNS work in this case?

There is no reverse DNS issue for sending mail. Usually nobody is checking
reverse DNS for the hosts they send mail *to*.
Reverse DNS is checked in case of hosts one receives mail *from*.


Sorry, I wasn't being clear here. What I mean to ask is if (and how) 
using a mail relay for sending mail could solve the problem that at the 
receiving end, reverse DNS does not match the originating domain.



(And unfortunately, switching to freedom.nl as a new ISP has one
drawback wrt. VOIP -- I can only keep one of our current two phone
lines.)

Why is this? Is your ISP also your VoIP provider?


Yes (although this is way off-topic here). ISP's here offer a package 
deal with Internet, TV, and at least one phone line for what used to be 
a 'land line'.



I use a VoIP provider that is independent from my ISP and I have set up two
phone lines in my VoIP router. For one line, SIP is listening on port 5060,
and for the other on port 5061. Both lines register with their appropriate
credentials to VoIP provider's SIP server (my VoIP provider is using
separate login & password for each phone line). This setup will work for
any ISP as long as ISP isn't blocking inbound UDP ports 5060/5061.


Perhaps I could do something like that, but then I'd have to spend more 
time on that as well. The whole point is that I had everything working 
perfectly fine, but that my current ISP demolished essential 
functionality without offering any solutions or alternatives.


So I'm still trying to figure out what my best option is -- and a better 
understanding of the whole mail server/relay thing is important, which 
is why I'm asking here :-)

Re: Solving reverse DNS problem with Postfix configuration?

[Benny Pedersen]

On 2022-04-12 14:20, Jaroslaw Rafa wrote:


Probably not, because smtp.xs4all.nl has IP address 195.121.65.191, and
reverse DNS for 195.121.65.191 is 195-121-65-191.dc.kpn.net. So it is 
also a
"generic" hostname which may cause some systems to reject mail sent 
from
this address. The ISP has configured it wrong; 195.121.65.191 should 
resolve

back to smtp.xs4all.nl.


its a dynamic ip, doh

https://multirbl.valli.org/lookup/195.121.65.191.html

Re: Solving reverse DNS problem with Postfix configuration?

[Benny Pedersen]

On 2022-04-12 14:07, Richard Rasker wrote:

Op 11-04-22 om 18:34 schreef Paul van der Vlis:

Hi Richard, ...



But according to the information supplied, I should also be able to
use smtp.xs4all.nl as a relay host, see
https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already took
care of the Spamhaus delisting).

Question: does this solve the PTR record problem?


on what ip ?

i can only give you lotto numbers in next google takeout :)

PTR is not relevant if using smtp sasl auth

relayhost need sasl auth else it would be open relay

more help post log and postconf -nf

Re: Solving reverse DNS problem with Postfix configuration?

[Jaroslaw Rafa]

Dnia 12.04.2022 o godz. 14:20:11 Jaroslaw Rafa pisze:
> Dnia 12.04.2022 o godz. 14:07:13 Richard Rasker pisze:
> > 
> > But according to the information supplied, I should also be able to
> > use smtp.xs4all.nl as a relay host, see
> > https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already
> > took care of the Spamhaus delisting).
> > 
> > Question: does this solve the PTR record problem?
> 
> Probably not, because smtp.xs4all.nl has IP address 195.121.65.191, and
> reverse DNS for 195.121.65.191 is 195-121-65-191.dc.kpn.net. So it is also a
> "generic" hostname which may cause some systems to reject mail sent from
> this address. The ISP has configured it wrong; 195.121.65.191 should resolve
> back to smtp.xs4all.nl.

Of course, it is possible that smtp.xs4all.nl is sending out emails from a
different IP address that it receives mail on, and that outgoing address has
a "good" reverse DNS. If this is the case, the problem will be solved. But
there is no way to know it until you try it and send a test email to
somewhere (it's best to send to some different address cotrolled by you, so
you can view the received message). Then the recipient can find that IP
address in "Received:" headers.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Solving reverse DNS problem with Postfix configuration?

[Jaroslaw Rafa]

Dnia 12.04.2022 o godz. 14:07:13 Richard Rasker pisze:
> 
> But according to the information supplied, I should also be able to
> use smtp.xs4all.nl as a relay host, see
> https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already
> took care of the Spamhaus delisting).
> 
> Question: does this solve the PTR record problem?

Probably not, because smtp.xs4all.nl has IP address 195.121.65.191, and
reverse DNS for 195.121.65.191 is 195-121-65-191.dc.kpn.net. So it is also a
"generic" hostname which may cause some systems to reject mail sent from
this address. The ISP has configured it wrong; 195.121.65.191 should resolve
back to smtp.xs4all.nl.

> >For sending e-mail, you don't need to change the MX record.
> 
> And how does reverse DNS work in this case?

There is no reverse DNS issue for sending mail. Usually nobody is checking
reverse DNS for the hosts they send mail *to*.
Reverse DNS is checked in case of hosts one receives mail *from*.

> (And unfortunately, switching to freedom.nl as a new ISP has one
> drawback wrt. VOIP -- I can only keep one of our current two phone
> lines.)

Why is this? Is your ISP also your VoIP provider?

I use a VoIP provider that is independent from my ISP and I have set up two
phone lines in my VoIP router. For one line, SIP is listening on port 5060,
and for the other on port 5061. Both lines register with their appropriate
credentials to VoIP provider's SIP server (my VoIP provider is using
separate login & password for each phone line). This setup will work for
any ISP as long as ISP isn't blocking inbound UDP ports 5060/5061.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Op 11-04-22 om 18:34 schreef Paul van der Vlis:
Hi Richard, 
...


Eventually you could use my mailserver as a relayhost. 


That is a very friendly offer, but if I do, that would of course only 
be temporary, so that I can send e-mail again, and I'd contact you in 
advance.


You need a username and password.


That's of course why I would contact you first :-)

But according to the information supplied, I should also be able to use 
smtp.xs4all.nl as a relay host, see 
https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already took 
care of the Spamhaus delisting).


Question: does this solve the PTR record problem?

Just to make sure: I guess I need to change my MX record for this to 
work? 


For sending e-mail, you don't need to change the MX record.


And how does reverse DNS work in this case? Sorry if I ask beginners' 
questions, but as I said, I never had to get into these details of mail 
servers and anti-spam measures -- up until yesterday, it 'Just Worked'.


(And unfortunately, switching to freedom.nl as a new ISP has one 
drawback wrt. VOIP -- I can only keep one of our current two phone lines.)



But maybe you need to change the SPF settings, if you have them.


Best regards,

Richard

Re: Solving reverse DNS problem with Postfix configuration?

[Paul van der Vlis]

Hi Richard,

Op 11-04-2022 om 18:20 schreef Richard Rasker:

Hi Paul,

Op 11-04-22 om 17:40 schreef Paul van der Vlis:


[snip]

Maybe switch to freedom.nl, they give you a good reverse DNS.
Also IPv6.


Thanks for the tip; I think that may be a good idea. They're a lot 
cheaper as well than XS4All/KPN -- I think I'll contact them first thing 
tomorrow morning to verify if they can indeed provide the services I was 
used to.




Eventually you could use my mailserver as a relayhost. 


That is a very friendly offer, but if I do, that would of course only be 
temporary, so that I can send e-mail again, and I'd contact you in advance.


You need a username and password.

Just to make sure: I guess I need to change my MX record for this to 
work? 


For sending e-mail, you don't need to change the MX record.

But maybe you need to change the SPF settings, if you have them.

Bye,
Paul

As I mentioned before, I'm not very proficient in mail server 
administration, mostly because Postfix, once it's up and running, Just 
Works -- for years on end.


Thanks once again, also to all the others who took time to reply,

Best regards,

Richard



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Solving reverse DNS problem with Postfix configuration?

[Viktor Dukhovni]

On Mon, Apr 11, 2022 at 06:20:46PM +0200, Richard Rasker wrote:

> That is a very friendly offer, but if I do, that would of course only be 
> temporary, so that I can send e-mail again, and I'd contact you in advance.
> 
> Just to make sure: I guess I need to change my MX record for this to 
> work?

Definitely NOT.  Inbound mail and outbound mail are often handled by
different servers, sometimes completely independent organisations.

Since your problem is only in the outbound direction, you only need to
change your "relayhost".  You can and should continue to receive inbound
mail on your own SMTP server.  PTR records are not needed for that.

For outbound mail, if you have any SPF records, you need to make sure
that any "relayhost" is listed in your SPF records.

-- 
Viktor.

Re: Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Hi Paul,

Op 11-04-22 om 17:40 schreef Paul van der Vlis:


[snip]

Maybe switch to freedom.nl, they give you a good reverse DNS.
Also IPv6.


Thanks for the tip; I think that may be a good idea. They're a lot 
cheaper as well than XS4All/KPN -- I think I'll contact them first thing 
tomorrow morning to verify if they can indeed provide the services I was 
used to.




Eventually you could use my mailserver as a relayhost. 


That is a very friendly offer, but if I do, that would of course only be 
temporary, so that I can send e-mail again, and I'd contact you in advance.


Just to make sure: I guess I need to change my MX record for this to 
work? As I mentioned before, I'm not very proficient in mail server 
administration, mostly because Postfix, once it's up and running, Just 
Works -- for years on end.


Thanks once again, also to all the others who took time to reply,

Best regards,

Richard

Re: Solving reverse DNS problem with Postfix configuration?

[Matus UHLAR - fantomas]

On 11.04.22 08:21, lists wrote:
FWIW my VPS only allows one reverse pointer.  I host multiple domains so 
only one reverse pointer will match.  My mail does not get bounced for 
that.


this is not about multiple PTRs records, this is about changing the PTR.

And before someone posts you can have more than one reverse pointer per IP 
the VPS (Digital Ocean) says it can't be done.


you can but it's rarely a good idea. And it's not a solution for the OP, 
because his original PTR causes problems, which means he needs to replace 
it, not to add another.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler

Re: Solving reverse DNS problem with Postfix configuration?

[Kris Deugau]

lists wrote:

FWIW my VPS only allows one reverse pointer. I host multiple domains so only 
one reverse pointer will match. My mail does not get bounced for that.

And before someone posts you can have more than one reverse pointer per IP the 
VPS (Digital Ocean) says it can't be done.


Multiple PTR records for a single IP are entirely possible - *if* the 
DNS management tool allows.  If DO says they "can't", it's a limitation 
of their DNS management tool.


It's usually not worth the effort, and may cause more problems that it 
solves.  Just set the PTR to the system's fully-qualified hostname and 
all but the pickiest of third-party mail systems will be happy.


-kgd

Re: Solving reverse DNS problem with Postfix configuration?

[Paul van der Vlis]

Op 11-04-2022 om 17:19 schreef Paul van der Vlis:

Hi Richard and others,

Op 11-04-2022 om 16:52 schreef Richard Rasker:


#Set Username and Password
  smtp_sasl_password_maps = static:Chosen-Username:Chosen-Password


What I use is this:
smtp_sasl_password_maps = hash:/etc/postfix/saslpasswd

And in that file something like:
smtp_sasl_password_maps = hash:/etc/postfix/saslpasswd


Wrong, must be:
mail.vandervlis.nlusername:secret


And then:
postmap /etc/postfix/saslpasswd

I then tried the same with mx.kpnmail.nl -- which is a mail host of my 
current ISP, which indeed has a valid PTR record, but still no mail 
appears to get through. So in order to post here, I changed things 
back for the time being. Perhaps I made a mistake in main.cf?


Maybe switch to freedom.nl, they give you a good reverse DNS.
Also IPv6.

Eventually you could use my mailserver as a relayhost.

Bye,
Paul



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Solving reverse DNS problem with Postfix configuration?

[lists]

FWIW my VPS only allows one reverse pointer. I host multiple domains so only 
one reverse pointer will match. My mail does not get bounced for that. 

And before someone posts you can have more than one reverse pointer per IP the 
VPS (Digital Ocean) says it can't be done. 





  Original Message  


From: m...@junc.eu
Sent: April 11, 2022 7:43 AM
To: postfix-users@postfix.org
Subject: Re: Solving reverse DNS problem with Postfix configuration?


On 2022-04-11 15:38, Richard Rasker wrote:

> Could I solve this by setting smtp_helo_name in main.cf to
> 77-172-184-9.fixed.kpn.net ? Or is this a bad idea?

no this will not solve it, you have to talk to isp kindly ask for change
of ptr, if thay are unvilling it most cases not a problem to change to
another isp that allows it

Re: Solving reverse DNS problem with Postfix configuration?

[Paul van der Vlis]

Hi Richard and others,

Op 11-04-2022 om 16:52 schreef Richard Rasker:


#Set Username and Password
  smtp_sasl_password_maps = static:Chosen-Username:Chosen-Password


What I use is this:
smtp_sasl_password_maps = hash:/etc/postfix/saslpasswd

And in that file something like:
smtp_sasl_password_maps = hash:/etc/postfix/saslpasswd

And then:
postmap /etc/postfix/saslpasswd

I then tried the same with mx.kpnmail.nl -- which is a mail host of my 
current ISP, which indeed has a valid PTR record, but still no mail 
appears to get through. So in order to post here, I changed things back 
for the time being. Perhaps I made a mistake in main.cf?


Maybe switch to freedom.nl, they give you a good reverse DNS.
Also IPv6.

Eventually you could use my mailserver as a relayhost.

Bye,
Paul

--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Solving reverse DNS problem with Postfix configuration?

[Benny Pedersen]

On 2022-04-11 17:00, Matus UHLAR - fantomas wrote:

On 11.04.22 15:38, Richard Rasker wrote:

I've been using Postfix for many years without significant problems.

However, due to a forced change in ISP, I can no longer have a 
correct PTR record pointing to mail.linetec.nl, causing a lot of 
ISP's to reject e-mail from my server.


Reverse DNS for my IP address now points to the ISP's generic name 
77-172-184-9.fixed.kpn.net


Could I solve this by setting smtp_helo_name in main.cf to 
77-172-184-9.fixed.kpn.net ? Or is this a bad idea?



Op 11-04-22 om 16:17 schreef Matus UHLAR - fantomas:
this will not help your problem. many ISPs will reject not because 
helo name but because of your reverse DNS format.


ask your ISP to change reverse DNS for your IP to mail.linetec.nl 
when possible.

if not possible, you'll need external smtp server, or different ISP.


On 11.04.22 16:52, Richard Rasker wrote:
Unfortunately, my new ISP says they can only do that for business 
accounts, which would cost me several dozen euros extra per month.


yes, quite common. One ISP even told me they only provide static IPs
to business accounts... Changing ISP is your possibility to check -
you have to find out which is cheaper or more reliable.


relayhost = smtp.xs4all.nl



#Enable Authentication
 smtp_sasl_auth_enable = yes
#Set Username and Password
 smtp_sasl_password_maps = static:Chosen-Username:Chosen-Password
 smtp_sasl_security_options = noanonymous
#Enable TLS Encryption
 smtp_tls_security_level = encrypt
 header_size_limit = 4096000
#Enable CA Certificates
 smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

When restarting Postfix, no mail at all seems to be getting through 
any more -- and how should this solve the reverse DNS problem? Because 
smtp.xs4all.nl has IP address 195.121.65.191, but this IP address 
again does not point back to smtp.xs4all.nl ...


https://multirbl.valli.org/lookup/195.121.65.191.html

seems dynamic ip, hence there ptr is correct !

did you provide another ip here ?


as I explained in different thread, this completely does not matter.
if no mail is getting through, there is different problem.

is there anything related to SMTP in your logs?

Perhaps you need to use different port (587 or 465 with
smtp_tls_wrappermode) with their smtp server. port 25 is often
blocked.


setup postfix to use gmail as smtp client with sasl auth is possible if 
all else fails


replace if needed gmail with another host you control

Re: Solving reverse DNS problem with Postfix configuration?

[Matus UHLAR - fantomas]

On 11.04.22 15:38, Richard Rasker wrote:

I've been using Postfix for many years without significant problems.

However, due to a forced change in ISP, I can no longer have a 
correct PTR record pointing to mail.linetec.nl, causing a lot of 
ISP's to reject e-mail from my server.


Reverse DNS for my IP address now points to the ISP's generic name 
77-172-184-9.fixed.kpn.net


Could I solve this by setting smtp_helo_name in main.cf to 
77-172-184-9.fixed.kpn.net ? Or is this a bad idea?



Op 11-04-22 om 16:17 schreef Matus UHLAR - fantomas:
this will not help your problem. many ISPs will reject not because 
helo name but because of your reverse DNS format.


ask your ISP to change reverse DNS for your IP to mail.linetec.nl 
when possible.

if not possible, you'll need external smtp server, or different ISP.


On 11.04.22 16:52, Richard Rasker wrote:
Unfortunately, my new ISP says they can only do that for business 
accounts, which would cost me several dozen euros extra per month.


yes, quite common. One ISP even told me they only provide static IPs to 
business accounts... Changing ISP is your possibility to check - 
you have to find out which is cheaper or more reliable.



relayhost = smtp.xs4all.nl



#Enable Authentication
 smtp_sasl_auth_enable = yes
#Set Username and Password
 smtp_sasl_password_maps = static:Chosen-Username:Chosen-Password
 smtp_sasl_security_options = noanonymous
#Enable TLS Encryption
 smtp_tls_security_level = encrypt
 header_size_limit = 4096000
#Enable CA Certificates
 smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

When restarting Postfix, no mail at all seems to be getting through 
any more -- and how should this solve the reverse DNS problem? Because 
smtp.xs4all.nl has IP address 195.121.65.191, but this IP address 
again does not point back to smtp.xs4all.nl ...


as I explained in different thread, this completely does not matter.
if no mail is getting through, there is different problem.

is there anything related to SMTP in your logs?

Perhaps you need to use different port (587 or 465 with 
smtp_tls_wrappermode) with their smtp server. port 25 is often blocked.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?

Re: Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Hello Matus, and others,

Op 11-04-22 om 16:17 schreef Matus UHLAR - fantomas:

On 11.04.22 15:38, Richard Rasker wrote:

I've been using Postfix for many years without significant problems.

However, due to a forced change in ISP, I can no longer have a 
correct PTR record pointing to mail.linetec.nl, causing a lot of 
ISP's to reject e-mail from my server.


Reverse DNS for my IP address now points to the ISP's generic name 
77-172-184-9.fixed.kpn.net


Could I solve this by setting smtp_helo_name in main.cf to 
77-172-184-9.fixed.kpn.net ? Or is this a bad idea?


this will not help your problem. many ISPs will reject not because 
helo name but because of your reverse DNS format.


ask your ISP to change reverse DNS for your IP to mail.linetec.nl when 
possible.

if not possible, you'll need external smtp server, or different ISP.


Thank you for your swift answers!

Unfortunately, my new ISP says they can only do that for business 
accounts, which would cost me several dozen euros extra per month. I'm 
pretty angry about this, because I explicitly chose my previous ISP 
(XS4All) for their excellent technical features & support -- and they 
did not warn me that their take-over by the current ISP (KPN) could have 
consequences like this.


After contacting the helpdesk (30 minutes waiting ...), I was told that 
I could configure Postfix to use a mail relay of the previous ISP, 
changing my MX record accordingly (smtp.xs4all.nl), but that doesn't 
appear to work properly either. But maybe I did something wrong -- I 
have no experience with relay servers yet.


This is what I added to my main.cfg, based on what I found on the Internet:

relayhost = smtp.xs4all.nl

... [further down]

#Enable Authentication
 smtp_sasl_auth_enable = yes
#Set Username and Password
 smtp_sasl_password_maps = static:Chosen-Username:Chosen-Password
 smtp_sasl_security_options = noanonymous
#Enable TLS Encryption
 smtp_tls_security_level = encrypt
 header_size_limit = 4096000
#Enable CA Certificates
 smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

When restarting Postfix, no mail at all seems to be getting through any 
more -- and how should this solve the reverse DNS problem? Because 
smtp.xs4all.nl has IP address 195.121.65.191, but this IP address again 
does not point back to smtp.xs4all.nl ...


I then tried the same with mx.kpnmail.nl -- which is a mail host of my 
current ISP, which indeed has a valid PTR record, but still no mail 
appears to get through. So in order to post here, I changed things back 
for the time being. Perhaps I made a mistake in main.cf?


Thanks again, best regards,

Richard

Re: Solving reverse DNS problem with Postfix configuration?

[Matus UHLAR - fantomas]

Could I solve this by setting smtp_helo_name in main.cf to 
77-172-184-9.fixed.kpn.net ?
Or is this a bad idea?


On 11.04.22 10:20, post...@ptld.com wrote:

Yes you can set the helo name to match but this wont have much effect.
Some servers are looking at domain -> IP -> domain which in your case is:

  mail.linetec.nl -> 77.172.184.9 -> 77-172-184-9.fixed.kpn.net


I don't think anyone resolves DNS in this order.
(and any indication of this may lead to false assumptions which is why I'm 
saying this).



the reverse DNS check usually goes like this:

77.172.184.9 -> 77-172-184-9.fixed.kpn.net -> 77.172.184.9

with the latter part sometimes ignored.

helo check goes like this:

"helo mail.linetec.nl" => mail.linetec.nl -> 77.172.184.9


with postfix, the first check is done by reject_unknown_client_hostname or 
the shorter way (without host=>IP resoluntion) by reject_unknown_reverse_client_hostname


the helo check is done by reject_unknown_helo_hostname.


however there are many mailservers who consider "77-172-184-9.fixed.kpn.net" 
generic (because it contains the IP address) and refuse talking to server.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95

Re: Solving reverse DNS problem with Postfix configuration?

[Benny Pedersen]

On 2022-04-11 15:38, Richard Rasker wrote:


Could I solve this by setting smtp_helo_name in main.cf to
77-172-184-9.fixed.kpn.net ? Or is this a bad idea?


no this will not solve it, you have to talk to isp kindly ask for change 
of ptr, if thay are unvilling it most cases not a problem to change to 
another isp that allows it

Re: Solving reverse DNS problem with Postfix configuration?

[postfix]

> Could I solve this by setting smtp_helo_name in main.cf to 
> 77-172-184-9.fixed.kpn.net ? 
> Or is this a bad idea?


Yes you can set the helo name to match but this wont have much effect.
Some servers are looking at domain -> IP -> domain which in your case is:

   mail.linetec.nl -> 77.172.184.9 -> 77-172-184-9.fixed.kpn.net

Since mail.linetec.nl does not equal 77-172-184-9.fixed.kpn.net they might 
decide to reject or mark the mail as spam. The helo name has nothing to do with 
that part. Some mail servers will then do an additional check on the helo name 
to see if it also matches or at least is a valid FQDN.

I have no idea on the percentage of servers that evaluate client FCrDNS. Having 
your IP listed as authorized in your SPF record for your domain could help in 
preventing mail being marked as spam.

Re: Solving reverse DNS problem with Postfix configuration?

[Matus UHLAR - fantomas]

On 11.04.22 15:38, Richard Rasker wrote:

I've been using Postfix for many years without significant problems.

However, due to a forced change in ISP, I can no longer have a correct 
PTR record pointing to mail.linetec.nl, causing a lot of ISP's to 
reject e-mail from my server.


Reverse DNS for my IP address now points to the ISP's generic name 
77-172-184-9.fixed.kpn.net


Could I solve this by setting smtp_helo_name in main.cf to 
77-172-184-9.fixed.kpn.net ? Or is this a bad idea?


this will not help your problem. many ISPs will reject not because helo name 
but because of your reverse DNS format.


ask your ISP to change reverse DNS for your IP to mail.linetec.nl when 
possible.

if not possible, you'll need external smtp server, or different ISP.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."

Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Hello,

I've been using Postfix for many years without significant problems.

However, due to a forced change in ISP, I can no longer have a correct 
PTR record pointing to mail.linetec.nl, causing a lot of ISP's to reject 
e-mail from my server.


Reverse DNS for my IP address now points to the ISP's generic name 
77-172-184-9.fixed.kpn.net


Could I solve this by setting smtp_helo_name in main.cf to 
77-172-184-9.fixed.kpn.net ? Or is this a bad idea?


Thanks for any suggestions,

Best regards,

Richard

Re: Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[raf]

On Thu, Sep 09, 2021 at 09:44:35AM +0200, TTM  wrote:

> raf wrote:
> >> main.cf
> >> -
> >> [...]
> >> receive_override_options = no_address_mappings
> >
> >I could be wrong, but I don't think you want the above setting.
> >You have canonical address maps and virtual alias maps, and
> >this setting disables them both.
> >
> >Normally, I think you'd only use this setting when there's an
> >external filter, and you want the address mappings to take
> >place after the filter so that the filter itself has access
> >to the original addresses. But you don't have a content_filter,
> >so address mapping is just completely disabled.
> >
> >  http://www.postfix.org/postconf.5.html#receive_override_options
> >
> >The above documentation doesn't specifically mention
> >"sender canonical address mapping", but it might be
> >implied where it refers to "canonical address mapping".
> >Not sure about that, but you did say that the address
> >rewriting isn't happening, so it probably is implied.
> 
> That's it! :)
> After removing it from the main.cf, the rewrite works.
> 
> Thanks a lot!
> 
> >
> >> smtp_sasl_security_options = noanonymous
> >
> >I'd leave the above at its more secure default value to
> >ensure that passwords can't be sent unencrypted. But
> >perhaps I just don't understand the reason why people
> >change this setting. But it probably never actually
> >results in passwords being sent unencrypted anyway, so
> >it probably doesn't really matter.
> I will look into it.
> 
> 
> >
> >> [...]
> >> smtpd_sasl_auth_enable = yes
> >
> >The above should probably be removed from main.cf and
> >added to the submission service in master.cf instead.
> 
> ok.
> I would say my problem is solved.
> Thanks.
> 
> --
> best regards,
> Thomas

Glad to hear it.

cheers,
raf

Re: Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[TTM]

raf wrote:
>> main.cf
>> -
>> [...]
>> receive_override_options = no_address_mappings
>
>I could be wrong, but I don't think you want the above setting.
>You have canonical address maps and virtual alias maps, and
>this setting disables them both.
>
>Normally, I think you'd only use this setting when there's an
>external filter, and you want the address mappings to take
>place after the filter so that the filter itself has access
>to the original addresses. But you don't have a content_filter,
>so address mapping is just completely disabled.
>
>  http://www.postfix.org/postconf.5.html#receive_override_options
>
>The above documentation doesn't specifically mention
>"sender canonical address mapping", but it might be
>implied where it refers to "canonical address mapping".
>Not sure about that, but you did say that the address
>rewriting isn't happening, so it probably is implied.

That's it! :)
After removing it from the main.cf, the rewrite works.

Thanks a lot!

>
>> smtp_sasl_security_options = noanonymous
>
>I'd leave the above at its more secure default value to
>ensure that passwords can't be sent unencrypted. But
>perhaps I just don't understand the reason why people
>change this setting. But it probably never actually
>results in passwords being sent unencrypted anyway, so
>it probably doesn't really matter.
I will look into it.


>
>> [...]
>> smtpd_sasl_auth_enable = yes
>
>The above should probably be removed from main.cf and
>added to the submission service in master.cf instead.

ok.
I would say my problem is solved.
Thanks.

--
best regards,
Thomas

Re: Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[raf]

On Wed, Sep 08, 2021 at 03:33:05PM +0200, fo...@gmx.de wrote:

> Hello together,
> I have "Ubuntu 20.04.3 LTS" on a raspberry pi 4, and I'm trying to config 
> postfix to rewrite local-addresses and use then sender-dependent relayhosts.
> 
> Postfix is mail_version = 3.4.13 and i have a dynamic IP.
> 
> The setup looks /should be like this:
> 
> 1) local user sends email to postfix (local emailserver)
> 2) postfix rewrites FROM Address
> 3) dependent on the rewriten FROM Address pick the right relayhost
> 4) submits the mail to the relayhost via port 587 with the credentials from 
> pass_smarthost
> 
> For point 1) an 2) i have a file sender_canonical created:
> -
> Local_User_A@local.homenet us...@gmx.de
> Local_User_B@local.homenet us...@gmail.com
> -
> 
> For point 3) i have a file relaymap created:
> -
> @gmx.de mail.gmx.net:587
> @gmail.com smtp.gmail.com:587
> -
> 
> For point 4) i have a file pass_smarthost created:
> -
> us...@gmx.de us...@gmx.de:UserA-GMX-Password
> us...@gmail.com us...@gmail.com:UserB-Gmail-Password
> -
> 
> I tested it with this:
> -
> echo "test" | sendmail -f ttm  ...@posteo.de
> -
> 
> But currently i get:
> 
> tail -f /var/log/syslog | grep --line-buffered "postfix\|relay\|generic"
> -
> Sep  7 18:28:29 ubuntu-RPI4 postfix/pickup[24810]: 5CFF24028B: uid=0 
> from=
> Sep  7 18:28:29 ubuntu-RPI4 postfix/cleanup[24830]: 5CFF24028B: 
> message-id=<20210907182829.5CFF24028B@ttmsacer.homenet>
> Sep  7 18:28:29 ubuntu-RPI4 postfix/qmgr[24811]: 5CFF24028B: 
> from=, size=256, nrcpt=1 (queue active)
> Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
> mx04.posteo.de[185.67.36.64]:25: Connection refused
> Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
> mx01.posteo.de[185.67.36.61]:25: Connection refused
> Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
> mx01.posteo.de[185.67.36.62]:25: Connection refused
> Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
> mx03.posteo.de[185.67.36.63]:25: Connection refused
> Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
> mx03.posteo.de[185.67.36.70]:25: Connection refused
> Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: 5CFF24028B: 
> to=, relay=none, delay=0.51, delays=0.07/0.08/0.36/0, 
> dsn=4.4.1, status=deferred (connect to mx03.posteo.de[185.67.36.70]:25: 
> Connection refused)
> -
> 
> For me it looks like, that postfix tries to deliver the email directly
> to the recipient server on port 25 - instead of using the relayhost
> (here gmx.de).
> And the rewrite didnt come to the correct address - maybe a circle?
> After the rewrite the FROM Address should be the us...@gmx.de not 
> ttm@ttmsacer.homenet.
> 
> I tried to add the "-v" option in the master.cf to see more details or get a 
> hint whats going round.
> 
> But i didn't get the error. What am I missing? Any hint would be helpful.
> 
> Thank you in advance.
> 
> main.cf
> -
> [...]
> receive_override_options = no_address_mappings

I could be wrong, but I don't think you want the above setting.
You have canonical address maps and virtual alias maps, and
this setting disables them both.

Normally, I think you'd only use this setting when there's an
external filter, and you want the address mappings to take
place after the filter so that the filter itself has access
to the original addresses. But you don't have a content_filter,
so address mapping is just completely disabled.

  http://www.postfix.org/postconf.5.html#receive_override_options

The above documentation doesn't specifically mention
"sender canonical address mapping", but it might be
implied where it refers to "canonical address mapping".
Not sure about that, but you did say that the address
rewriting isn't happening, so it probably is implied.

> [...]
> sender_canonical_maps = hash:/etc/postfix/sender_canonical
> sender_dependent_relayhost_maps = hash:/etc/postfix/relaymap
> [...]
> smtp_generic_maps = hash:/etc/postfix/sender_canonical

Does it make sense to use the same map for
sender_canonical_maps and smtp_generic_maps? Perhaps it
does. It just struck me as possibly odd. Perhaps it's fine.

According to
http://www.postfix.org/ADDRESS_REWRITING_README.html,
the generic maps 

Re: Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[TTM]

Bernardo:
>You canonical map has:
>
>Local_User_A@local.homenet us...@gmx.de
>Local_User_B@local.homenet us...@gmail.com
>
>but according to the log your "from" is "ttm@ttmsacer.homenet".
>
>Your map doesn't contain/match anything related to "ttmsacer.homenet" (it only
>has entries for "local.homenet"), so postfix (rightly) uses the default relay.
>
>You'd need to have a line in your map for "ttm@ttmsacer.homenet".
>

You are right, the explanation is with example email addresses (to
explain the concept with my words) and the log is real.

In the file "sender_canonical" is the first entry with
"ttm@ttmsacer.homenet" mapping to the related gmx address.

Based on the premise the file "sender_canonical" is correct, what could
be the next missing point?

Wietse mentioned that the Postfix cleanup daemon is responsible for
rewriting the FROM address.

Best regards,
Thomas

Re: Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[Bernardo Reino]

On Wed, 8 Sep 2021, TTM wrote:


Wietse:

Without further information I can't say what mistake you made. Maybe
you're looking at an old message that is already in the queue.


What would be needed?
After each test, I clear thee queue with "postsuper -d ALL".

I'm wondering why postfix tries to deliver the message directly to the
recipient host on port 25 instead of using the relaymap.

At the moment i thing, the issue is connected with the missing rewrite
of the local address.

But here I need a hint. :-)


Wietse already have you the hint, or rather, the actual cause of your problem :)

You canonical map has:

Local_User_A@local.homenet us...@gmx.de
Local_User_B@local.homenet us...@gmail.com

but according to the log your "from" is "ttm@ttmsacer.homenet".

Your map doesn't contain/match anything related to "ttmsacer.homenet" (it only 
has entries for "local.homenet"), so postfix (rightly) uses the default relay.


You'd need to have a line in your map for "ttm@ttmsacer.homenet".

Cheers,
Bernardo

Re: Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[Wietse Venema]

TTM:
> 
> Wietse:
> >The Postfix cleanup daemon applies canonical mapping before it
> >writes a message to a queue file.
> 
> Ok, I misunderstood this note in the postfix docu:
> "Note: $sender_canonical_maps is processed before $canonical_maps. "
> 
> 
> Ok, but can I achieve it by setting in main.cf:
> -
> canonical_maps = hash:/etc/postfix/sender_canonical
> -
> 
> The result didn't change, after a try out.

Without further information I can't say what mistake you made. Maybe
you're looking at an old message that is already in the queue.

You can use the postmap command to query the sender_canonical file.

Wietse

Re: Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[TTM]

Wietse:
>The Postfix cleanup daemon applies canonical mapping before it
>writes a message to a queue file.

Ok, I misunderstood this note in the postfix docu:
"Note: $sender_canonical_maps is processed before $canonical_maps. "


Ok, but can I achieve it by setting in main.cf:
-
canonical_maps = hash:/etc/postfix/sender_canonical
-

The result didn't change, after a try out.

Wietse:
>And therefore your sender_dependent relay rules are ineffective.

Where could it be effective?

--
best regards,
thomas


>
>fo...@gmx.de:
>> For point 1) an 2) i have a file sender_canonical created:
>> -
>> Local_User_A@local.homenet us...@gmx.de
>> Local_User_B@local.homenet us...@gmail.com
>> -
>>
>
>The Postfix cleanup daemon applies canonical mapping before it
>writes a message to a queue file.
>
>The Postfix queue manager logging shows that those rules did not
>match your sender address ttm@ttmsacer.homenet
>
>> Sep  7 18:28:29 ubuntu-RPI4 postfix/qmgr[24811]: 5CFF24028B:
>> from=, size=256, nrcpt=1 (queue active)
>
>And therefore your sender_dependent relay rules are ineffective.
>
>   Wietse

Re: Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[Wietse Venema]

fo...@gmx.de:
> For point 1) an 2) i have a file sender_canonical created:
> -
> Local_User_A@local.homenet us...@gmx.de
> Local_User_B@local.homenet us...@gmail.com
> -

The Postfix cleanup daemon applies canonical mapping before it
writes a message to a queue file.

The Postfix queue manager logging shows that those rules did not
match your sender address ttm@ttmsacer.homenet

> Sep  7 18:28:29 ubuntu-RPI4 postfix/qmgr[24811]: 5CFF24028B: 
> from=, size=256, nrcpt=1 (queue active)

And therefore your sender_dependent relay rules are ineffective.

Wietse

Local address rewrite problem with postfix configuration and sender dependent relayhosts - ISP

[forTT]

Hello together,
I have "Ubuntu 20.04.3 LTS" on a raspberry pi 4, and I'm trying to config 
postfix to rewrite local-addresses and use then sender-dependent relayhosts.

Postfix is mail_version = 3.4.13 and i have a dynamic IP.


The setup looks /should be like this:

1) local user sends email to postfix (local emailserver)
2) postfix rewrites FROM Address
3) dependent on the rewriten FROM Address pick the right relayhost
4) submits the mail to the relayhost via port 587 with the credentials from 
pass_smarthost


For point 1) an 2) i have a file sender_canonical created:
-
Local_User_A@local.homenet us...@gmx.de
Local_User_B@local.homenet us...@gmail.com
-

For point 3) i have a file relaymap created:
-
@gmx.de mail.gmx.net:587
@gmail.com smtp.gmail.com:587
-

For point 4) i have a file pass_smarthost created:
-
us...@gmx.de us...@gmx.de:UserA-GMX-Password
us...@gmail.com us...@gmail.com:UserB-Gmail-Password
-

I tested it with this:
-
echo "test" | sendmail -f ttm  ...@posteo.de
-

But currently i get:

tail -f /var/log/syslog | grep --line-buffered "postfix\|relay\|generic"
-
Sep  7 18:28:29 ubuntu-RPI4 postfix/pickup[24810]: 5CFF24028B: uid=0 from=
Sep  7 18:28:29 ubuntu-RPI4 postfix/cleanup[24830]: 5CFF24028B: 
message-id=<20210907182829.5CFF24028B@ttmsacer.homenet>
Sep  7 18:28:29 ubuntu-RPI4 postfix/qmgr[24811]: 5CFF24028B: 
from=, size=256, nrcpt=1 (queue active)
Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
mx04.posteo.de[185.67.36.64]:25: Connection refused
Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
mx01.posteo.de[185.67.36.61]:25: Connection refused
Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
mx01.posteo.de[185.67.36.62]:25: Connection refused
Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
mx03.posteo.de[185.67.36.63]:25: Connection refused
Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: connect to 
mx03.posteo.de[185.67.36.70]:25: Connection refused
Sep  7 18:28:29 ubuntu-RPI4 postfix/smtp[24833]: 5CFF24028B: 
to=, relay=none, delay=0.51, delays=0.07/0.08/0.36/0, 
dsn=4.4.1, status=deferred (connect to mx03.posteo.de[185.67.36.70]:25: 
Connection refused)
-

For me it looks like, that postfix tries to deliver the email directly
to the recipient server on port 25 - instead of using the relayhost
(here gmx.de).
And the rewrite didnt come to the correct address - maybe a circle?
After the rewrite the FROM Address should be the us...@gmx.de not 
ttm@ttmsacer.homenet.

I tried to add the "-v" option in the master.cf to see more details or get a 
hint whats going round.

But i didn't get the error. What am I missing? Any hint would be helpful.

Thank you in advance.



main.cf
-
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = no
compatibility_level = 2
inet_interfaces = 127.0.0.1, localhost, 192.168.178.20
inet_protocols = all
local_transport = virtual
mailbox_size_limit = 0
message_size_limit = 52768000
mydestination = localhost.homenet, localhost
mydomain = ttmsacer.homenet
myhostname = ubuntu-RPI4.homenet
mynetworks = 127.0.0.0/8, [:::127.0.0.0]/104, [::1]/128, 192.168.178.0/24
myorigin = /etc/mailname
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps 
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains 
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps 
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks 
$smtpd_sender_login_maps
readme_directory = no
receive_override_options = no_address_mappings
recipient_delimiter = +
relayhost =
sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sender_dependent_relayhost_maps = hash:/etc/postfix/relaymap
smtp_connection_cache_on_demand = no
smtp_generic_maps = hash:/etc/postfix/sender_canonical
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/pass_smarthost
smtp_sasl_security_options = noanonymous
smtp_sender_dependent_authentication = yes
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_security_level = may
smtp_tls_session_cache_database = 

Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?

[Dominic Raferd]

On 07/12/2020 14:58, Chris Green wrote:

On Mon, Dec 07, 2020 at 02:34:14PM +, Dominic Raferd wrote:

On 07/12/2020 13:11, Chris Green wrote:

On Mon, Dec 07, 2020 at 01:01:16PM +, Chris Green wrote:
[snip]


While I'm about it why am I getting identical mail.log and mail.info
files created in /var/log on the Pi?
I could still do with an answer to this.


Check contents of /etc/rsyslog.d (e.g. 50-default.conf) and docs at
www.rsyslog.com/doc/

Yes, thanks (and Wietse), the Raspberry Pi default rsyslog
configuration has:-

 mail.*  -/var/log/mail.log
 ...
 ...
 mail.info   -/var/log/mail.info
 mail.warn   -/var/log/mail.warn
 mail.err/var/log/mail.err

Sorry for the noise.  I'll go quiet again soon when I've got Postfix
properly configured on these systems I've just added it to.


If immediately after the line beginning 'mail.*'  you insert a line:

& stop

this will stop any further mail facility logging. Or delete the later lines.

You will have to restart rsyslogd afterwards e.g. systemctl restart rsyslog

OT: syslog output files (Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?)

[Kris Deugau]

Chris Green wrote:

While I'm about it why am I getting identical mail.log and mail.info
files created in /var/log on the Pi?


It's not inherently Pi-specific.

The root cause is some wise-guy upstream package maintainer who has 
(mis?)configured (r)syslog to output multiple log files for different 
priority messages sent to the MAIL facilty by default.  Whether this is 
actually useful is entirely a matter of opinion.


One of the first things I do in a new Debian install is to revert this 
to the standard single file.  Personally I have yet to find a use case 
where this split would be useful, notwithstanding the packager's 
comments in the rsyslog configuration.


-kgd

Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?

[Chris Green]

On Mon, Dec 07, 2020 at 02:34:14PM +, Dominic Raferd wrote:
> On 07/12/2020 13:11, Chris Green wrote:
> > On Mon, Dec 07, 2020 at 01:01:16PM +, Chris Green wrote:
> > [snip]
> > 
> > > 
> > > While I'm about it why am I getting identical mail.log and mail.info
> > > files created in /var/log on the Pi?
> > > I could still do with an answer to this.
> > > 
> Check contents of /etc/rsyslog.d (e.g. 50-default.conf) and docs at
> www.rsyslog.com/doc/

Yes, thanks (and Wietse), the Raspberry Pi default rsyslog
configuration has:-

mail.*  -/var/log/mail.log
...
...
mail.info   -/var/log/mail.info
mail.warn   -/var/log/mail.warn
mail.err/var/log/mail.err

Sorry for the noise.  I'll go quiet again soon when I've got Postfix
properly configured on these systems I've just added it to.

-- 
Chris Green

Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?

[Dominic Raferd]

On 07/12/2020 13:11, Chris Green wrote:

On Mon, Dec 07, 2020 at 01:01:16PM +, Chris Green wrote:
[snip]



While I'm about it why am I getting identical mail.log and mail.info
files created in /var/log on the Pi?
I could still do with an answer to this.

Check contents of /etc/rsyslog.d (e.g. 50-default.conf) and docs at 
www.rsyslog.com/doc/

Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?

[Wietse Venema]

Chris Green:
> > While I'm about it why am I getting identical mail.log and mail.info
> > files created in /var/log on the Pi?
> > 
> I could still do with an answer to this.

Postfix does not write those files. They are written by diffferent
programs: rsyslog, syslogd, or the like.

Wietse

Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?

[Chris Green]

On Mon, Dec 07, 2020 at 01:01:16PM +, Chris Green wrote:
[snip]
>
> Presumably this means there's a SASL/TLS library I need to install on
> the Pi, can anyone tell me what it is please.  Oh, I have run 'postmap
> /etc/postfix/sasl_passwd' on both systems.
> 

Typical! Almost immediately after posting the question I found the
solution.  Careful comparison of what's installed on the Pi compared
with the Ubuntu system showed that libsasl2-modules was needed (I had 
libsasl2-modules-db already).  Installing libsasl2-modules has fixed
my problem.

> 
> 
> While I'm about it why am I getting identical mail.log and mail.info
> files created in /var/log on the Pi?
> 
I could still do with an answer to this.

-- 
Chris Green

'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?

[Chris Green]

I am setting up a 'send only' Postfix configuration on a number of
machines so that they can send error messages to me on my desktop
machine.

The main.cf file is:-

compatibility_level = 2
#
#
# TLS parameters
#
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
#
#
# This is the actual 'custom' configuration
#
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydomain = zbmc.eu
myorigin = $mydomain
relayhost = [mail.gandi.net]:465
#
#
# We don't accept any incoming connections
#
mydestination =
inet_interfaces = loopback-only
#
#
# SASL configuration for connecting to Gandi (or TsoHost)
#
smtp_sasl_auth_enable = yes
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd


I'm running postfix 3.4.13 on the Ubuntu laptop, 3.4.14 on the
Raspberry Pi. 

It's working fine on the Ubuntu laptop but on the Raspberry Pi I'm
getting the following error reported in mail.warn :-

Dec  7 12:52:16 dns postfix/smtp[15473]: warning: SASL authentication 
failure: No worthy mechs found

Presumably this means there's a SASL/TLS library I need to install on
the Pi, can anyone tell me what it is please.  Oh, I have run 'postmap
/etc/postfix/sasl_passwd' on both systems.



While I'm about it why am I getting identical mail.log and mail.info
files created in /var/log on the Pi?

-- 
Chris Green

Re: 'mlmmj' and Postfix configuration

[Wietse Venema]

Gerard E. Seibert:
> I am considering running 'mlmmj' on my FreeBSD system. There is a
> document that shows how to configure Postfix with 'mlmmj' available.
> http://mlmmj.org/docs/readme-postfix/ That document is dated 1/28/2012.
> I tend to think it is outdated.

It uses stable Postfix interfaces: virtual_alias_maps, transport_maps,
and the pipe delivery agent. Those work like 20 years ago. Except
for the compatibility_level changes from Postfix 2 to Postfix 3,
new behavior has been mostly additive.

Wietse

> Does anyone here use this application and have any suggestions on how to
> configure it and/or Postfix to work happily together?
> 
> Thanks!
> 
> -- 
> Gerard
-- End of PGP section, PGP failed!

Re: 'mlmmj' and Postfix configuration

[Benny Pedersen]

On 2020-05-13 19:09, Gerard E. Seibert wrote:

Does anyone here use this application and have any suggestions on how 
to

configure it and/or Postfix to work happily together?


its dokumented imho on that page how to make it work

'mlmmj' and Postfix configuration

[Gerard E. Seibert]

I am considering running 'mlmmj' on my FreeBSD system. There is a
document that shows how to configure Postfix with 'mlmmj' available.
http://mlmmj.org/docs/readme-postfix/ That document is dated 1/28/2012.
I tend to think it is outdated.

Does anyone here use this application and have any suggestions on how to
configure it and/or Postfix to work happily together?

Thanks!

-- 
Gerard


pgp5uw2F_pffZ.pgp
Description: OpenPGP digital signature

Postfix configuration

[forums]

Hi, 

Sorry for my english, I'm french. 

I have some doubts about my Postfix configuration. 

I have a private mail server, at my home, allowing me to have my
personal e-mails ( @my_domain.fr ) 

My architecture is the following one (on Raspberry Pi with Raspbian): 

- 1 mail server with Postfix, Dovecot, Amavis, Spamassassin, ClamAV 

- 3 others severs, not mail servers 

I can send and receive e-mails, from inside and outside without any
problem. 

I use a SMTP relay (my provider SMTP). 

I have a domain and the MX record is OK. 

But I'm not sure about my Postfix configuration. 

Here it is: 

* main.cf: 

_SMTPD_BANNER = $MYHOSTNAME ESMTP $MAIL_NAME (RASPBIAN)_
_BIFF = NO_
_APPEND_DOT_MYDOMAIN = NO_
_#DELAY_WARNING_TIME = 4H_
_README_DIRECTORY = NO_
_# TLS PARAMETERS_
_SMTPD_TLS_CERT_FILE=/DIRECTORY_OF_SSL_FILES/FULLCHAIN.PEM_
_SMTPD_TLS_KEY_FILE=/DIRECTORY_OF_SSL_FILES/PRIVKEY.PEM_
_SMTPD_TLS_CAFILE=/DIRECTORY_OF_SSL_FILES/CHAIN.PEM_
_SMTPD_USE_TLS=YES_
_SMTPD_TLS_SESSION_CACHE_DATABASE =
BTREE:${DATA_DIRECTORY}/SMTPD_SCACHE_
_SMTPD_TLS_SECURITY_LEVEL = MAY_
_SMTP_TLS_CERT_FILE=/DIRECTORY_OF_SSL_FILES/FULLCHAIN.PEM_
_SMTP_TLS_KEY_FILE=/DIRECTORY_OF_SSL_FILES/PRIVKEY.PEM_
_SMTP_TLS_CAFILE=/DIRECTORY_OF_SSL_FILES/CHAIN.PEM_
_SMTP_USE_TLS=YES_
_SMTP_TLS_SESSION_CACHE_DATABASE = BTREE:${DATA_DIRECTORY}/SMTP_SCACHE_
_SMTPD_RELAY_RESTRICTIONS = PERMIT_MYNETWORKS,
PERMIT_SASL_AUTHENTICATED, DEFER_UNAUTH_DESTINATION_
_#MYHOSTNAME = MY_HOSTNAME_
_ALIAS_MAPS = HASH:/ETC/ALIASES_
_ALIAS_DATABASE = HASH:/ETC/ALIASES_
_MYORIGIN = MY_DOMAIN.FR_
_MYDESTINATION = MY_SERVER1, MY_SERVER2, MY_SERVER3_
_RELAYHOST = [IP_RELAY_HOST]:25_
_MYNETWORKS = 127.0.0.0/8 192.168.1.0/24_
_MAILBOX_SIZE_LIMIT = 1024_
_RECIPIENT_DELIMITER = +_
_INET_INTERFACES = ALL_
_INET_PROTOCOLS = IPV4_
_VIRTUAL_MAILBOX_DOMAINS =
MYSQL:/ETC/POSTFIX/MYSQL-VIRTUAL-MAILBOX-DOMAINS.CF_
_VIRTUAL_MAILBOX_MAPS =
MYSQL:/ETC/POSTFIX/MYSQL-VIRTUAL-MAILBOX-MAPS.CF_
_VIRTUAL_ALIAS_MAPS = MYSQL:/ETC/POSTFIX/MYSQL-VIRTUAL-ALIAS-MAPS.CF_
_# SASL_
_SMTPD_SASL_TYPE = DOVECOT_
_SMTPD_SASL_PATH = PRIVATE/AUTH_
_SMTP_SASL_AUTH_ENABLE = YES_
_SMTP_SASL_SECURITY_OPTIONS = NOANONYMOUS_
_SMTP_SASL_PASSWORD_MAPS = HASH:/ETC/POSTFIX/SASL/SASL_PASSWD_
_SMTPD_RECIPIENT_RESTRICTIONS = PERMIT_SASL_AUTHENTICATED,
PERMIT_MYNETWORKS, REJECT_UNAUTH_DESTINATION_
_VIRTUAL_TRANSPORT = DOVECOT_
_DOVECOT_DESTINATION_RECIPIENT_LIMIT = 1_
_CONTENT_FILTER = SMTP-AMAVIS:[127.0.0.1]:10024_
_#SENDER_CANONICAL_MAPS = HASH:/ETC/POSTFIX/CANONICAL_
_# TAILLE DES PIÈCES JOINTES_
_MESSAGE_SIZE_LIMIT = 2048_
_COMPATIBILITY_LEVEL = 2_ 

* master.cf: 

_#_
_# POSTFIX MASTER PROCESS CONFIGURATION FILE.  FOR DETAILS ON THE
FORMAT_
_# OF THE FILE, SEE THE MASTER(5) MANUAL PAGE (COMMAND: "MAN 5 MASTER"
OR_
_# ON-LINE: HTTP://WWW.POSTFIX.ORG/MASTER.5.HTML)._
_#_
_# DO NOT FORGET TO EXECUTE "POSTFIX RELOAD" AFTER EDITING THIS FILE._
_#_
_#
==_
_# SERVICE TYPE  PRIVATE UNPRIV  CHROOT  WAKEUP  MAXPROC COMMAND + ARGS_
_#   (YES)   (YES)   (YES)   (NEVER) (100)_
_#
==_
_#SMTP  INET  N   -   -   -   1   POSTSCREEN_
_#SMTPD PASS  -   -   -   -   -   SMTPD_
_#DNSBLOG   UNIX  -   -   -   -   0   DNSBLOG_
_#TLSPROXY  UNIX  -   -   -   -   0   TLSPROXY_
_SMTP   INET  N   -   Y   -   -   SMTPD_
_#  -O SYSLOG_NAME=POSTFIX/SUBMISSION_
_#  -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_
_SUBMISSION INET  N   -   Y   -   -   SMTPD_
_-O SMTPD_TLS_SECURITY_LEVEL=MAY_
_-O SMTPD_SASL_AUTH_ENABLE=YES_
_-O MILTER_MACRO_DAEMON_NAME=ORIGINATING_
_#  -O SYSLOG_NAME=POSTFIX/SMTPS_
_#  -O SMTPD_TLS_WRAPPERMODE=YES_
_#  -O SMTPD_REJECT_UNLISTED_RECIPIENT=NO_
_#  -O SMTPD_HELO_RESTRICTIONS=$MUA_HELO_RESTRICTIONS_
_#  -O SMTPD_RELAY_RESTRICTIONS=PERMIT_SASL_AUTHENTICATED,REJECT_
_#  -O MILTER_MACRO_DAEMON_NAME=ORIGINATING_
_SMTPS  INET  N   -   Y   -   -   SMTPD_
_-O SMTPD_SASL_AUTH_ENABLE=YES_
_-O SMTPD_TLS_SECURITY_LEVEL=ENCRYPT_
_-O SMTPD_SASL_AUTH_ENABLE=YES_
_-O SMTPD_SASL_TYPE=DOVECOT_
_-O SMTPD_SASL_PATH=PRIVATE/AUTH_
_-O SMTPD_SASL_SECURITY_OPTIONS=NOANONYMOUS_
_-O SMTPD_SASL_LOCAL_DOMAIN=$MYHOSTNAME_
_-O SMTPD_CLIENT_RESTRICTIONS=PERMIT_SASL_AUTHENTICATED,REJECT_
_-O SMTPD_SENDER_RESTRICTIONS=REJECT_SENDER_LOGIN_MISMATCH_
_-O
SMTPD_RECIPIENT_RESTRICTIONS=REJECT_NON_FQDN_RECIPIENT,REJECT_UNKNOWN_RECIPIENT_DOMAIN,PERMIT_SASL_AUTHENTICATED,REJECT_
_SMTP-AMAVIS UNIX - 

Re: ETRN use and Postfix configuration

[J Doe]

Hi LuKreme,

> On Mar 4, 2018, at 8:44 AM, LuKreme  wrote:
> 
> Isn't ETRN a good thing? What's the benefit from disabling it?
> -- 
> My main job is trying to come up with new and innovative and effective ways 
> to reject even more mail. I'm up to about 97% now.
> 

It’s a good thing in that it is an improvement over the original TURN verb with 
some security as opposed to no security.

RFC 1985 (ETRN) makes two use cases for this:

**  Startup conditions
**  “..mail nodes that have transient connections to their service 
providers”

The last point is referring to when someone had a gateway SMTP server that used 
to periodically dial up an ISP and exchange e-mail with it, server to server.  
That was common in the 90’s (which is when the RFC was submitted), but you’d be 
pretty hard pressed to find that now.

Postfix supports fast ETRN [1], which has performance optimizations over what 
other implementations provide, but you have to explicitly configure it to use 
it.  From my original e-mail I learned from the list how to squelch the 
advertisement on EHLO and ensure that it was not configured, either.

Sources:

[1] http://www.postfix.org/ETRN_README.html

Re: ETRN use and Postfix configuration

[Wietse Venema]

LuKreme:
> On Feb 27, 2018, at 18:29, J Doe  wrote:
> > postscreen_discard_ehlo_keywords
> >smtpd_discard_ehlo_keywords
> 
> Isn't ETRN a good thing? What's the benefit from disabling it?

Good if used by the right client (who needs this nowadays?), otherwise
ERTN it is a waste of scheduler resources.

Wietse

Re: ETRN use and Postfix configuration

[LuKreme]

On Feb 27, 2018, at 18:29, J Doe  wrote:
> postscreen_discard_ehlo_keywords
>smtpd_discard_ehlo_keywords

Isn't ETRN a good thing? What's the benefit from disabling it?
-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: ETRN use and Postfix configuration

[J Doe]

Hi Noel,

> On Feb 27, 2018, at 10:18 PM, Noel Jones  wrote:
>> ** Is Postfix logging that ETRN is disabled on the first, unencrypted SMTP 
>> session and then logging this again for the encrypted session (ie: Postfix 
>> is just logging I disabled this and Google is not attempting to issue ETRN 
>> each time) ?
> 
> Yes, this. The informative message is logged as soon as the client
> sends EHLO, and before the client sends any other commands.
> 
> Now that you know it's working, you can use the silent_discard
> keyword to clean up the logs.
> 
>  -- Noel Jones

Thanks for you reply.  Ok, good to know; I will prepend silent_discard to the 
list.

- J

Re: ETRN use and Postfix configuration

[Noel Jones]

On 2/27/2018 8:29 PM, J Doe wrote:
> Hello,
> 
> I read the “Postfix ETRN Howto” [1] as well as man 5 postconf with regards to:
> 
> postscreen_discard_ehlo_keywords
> smtpd_discard_ehlo_keywords
> 
> ... and disabled the announcement of ETRN via:
> 
> postscreen_discard_ehlo_keywords = ETRN
> smtpd_discard_ehlo_keywords = ETRN
> 
> I then restarted the server and observed an inbound connection from Gmail:
> 
> Feb 27 21:12:19 server postfix/smtpd[2369]: connect from 
> mail-oi0-x22f.google.com
> Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN
> Feb 27 21:12:19 server postfix/smtpd[2369]: Trusted TLS connection 
> established ...
> Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN
> 
> My question is:
> 
> ** Is the Gmail SMTP server attempting to use ETRN on the first, unencrypted 
> SMTP session with my server and then attempting to request it again after 
> STARTTLS when the TLS connection is established and this is why it is logging 
> that it is discarding ETRN each time or ...

Not this.

> 
> ** Is Postfix logging that ETRN is disabled on the first, unencrypted SMTP 
> session and then logging this again for the encrypted session (ie: Postfix is 
> just logging I disabled this and Google is not attempting to issue ETRN each 
> time) ?

Yes, this. The informative message is logged as soon as the client
sends EHLO, and before the client sends any other commands.

Now that you know it's working, you can use the silent_discard
keyword to clean up the logs.



  -- Noel Jones

ETRN use and Postfix configuration

[J Doe]

Hello,

I read the “Postfix ETRN Howto” [1] as well as man 5 postconf with regards to:

postscreen_discard_ehlo_keywords
smtpd_discard_ehlo_keywords

... and disabled the announcement of ETRN via:

postscreen_discard_ehlo_keywords = ETRN
smtpd_discard_ehlo_keywords = ETRN

I then restarted the server and observed an inbound connection from Gmail:

Feb 27 21:12:19 server postfix/smtpd[2369]: connect from 
mail-oi0-x22f.google.com
Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN
Feb 27 21:12:19 server postfix/smtpd[2369]: Trusted TLS connection established 
...
Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN

My question is:

** Is the Gmail SMTP server attempting to use ETRN on the first, unencrypted 
SMTP session with my server and then attempting to request it again after 
STARTTLS when the TLS connection is established and this is why it is logging 
that it is discarding ETRN each time or ...

** Is Postfix logging that ETRN is disabled on the first, unencrypted SMTP 
session and then logging this again for the encrypted session (ie: Postfix is 
just logging I disabled this and Google is not attempting to issue ETRN each 
time) ?

Thanks,

- J

Sources:
[1] www.postfix.org/ETRN_README.html

Postfix configuration postconf

[John]

Is there a way of checking for /unnecessary/ entries in the Postfix main 
or master config files.
I was looking through the mailing list and noticed the point that Victor 
made about smtpd_tls_session_cache_database being mostly unnecessary.
This made me wonder if I have entries in the config files that are 
duplicating defaults. The obvious method would be to check each entry 
against the manual, however, probably over thinking this, I wondered if 
the manual and my distribution (Debian Jessie) my be different.


--
John Allen
KLaM
--
If you are out to describe the truth, leave elegance to the tailor.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Postfix configuration postconf

[Koko Wijatmoko]

On Sun, 8 Feb 2015 05:55:47 -0500
John j...@klam.ca wrote:

 Is there a way of checking for /unnecessary/ entries in the Postfix
 main or master config files.
 I was looking through the mailing list and noticed the point that
 Victor made about smtpd_tls_session_cache_database being mostly
 unnecessary. This made me wonder if I have entries in the config
 files that are duplicating defaults. The obvious method would be to
 check each entry against the manual, however, probably over thinking
 this, I wondered if the manual and my distribution (Debian Jessie) my
 be different.
 
postconf -n or postconf -d is not working for you?

http://www.postfix.org/postconf.1.html

Re: Solved : Postfix configuration postconf

[Wietse Venema]

John:
  postconf -n or postconf -d is not working for you?
 
  http://www.postfix.org/postconf.1.html
 They work very well. But they do not tell me when and what options I may 
 have added to my config which duplicate a default option. While such 
 duplications are not disasters they make the config files that bit more 
 complex than they need to be.
 
 Actually I realized that I had a simple solution at hand in meld.

To enumerate the settings that duplicate the built-in defaults:

$ (postconf -n; postconf -d) | sort | uniq -c | awk '$1  1'

However, some of these redundant settings are install parameters
with the location of files/directories. You may want to keep those
parameters for the case that you upgrade an existing Postfix system
to a version that uses different default file/directory locations.

Wietse

Re: Postfix configuration postconf

[btb]

 On Feb 08, 2015, at 05.55, John j...@klam.ca wrote:
 
 Is there a way of checking for unnecessary entries in the Postfix main or 
 master config files.
 I was looking through the mailing list and noticed the point that Victor made 
 about smtpd_tls_session_cache_database being mostly unnecessary. 
 This made me wonder if I have entries in the config files that are 
 duplicating defaults. The obvious method would be to check each entry against 
 the manual, however, probably over thinking this, I wondered if the manual 
 and my distribution (Debian Jessie) my be different.

i use this to reveal duplicates in main.cf:

(postconf -d; postconf -n) | sort | uniq -d

-ben

Solved : Postfix configuration postconf

[John]

On 2/8/2015 7:06 AM, Koko Wijatmoko wrote:

On Sun, 8 Feb 2015 05:55:47 -0500
John j...@klam.ca wrote:


Is there a way of checking for /unnecessary/ entries in the Postfix
main or master config files.
I was looking through the mailing list and noticed the point that
Victor made about smtpd_tls_session_cache_database being mostly
unnecessary. This made me wonder if I have entries in the config
files that are duplicating defaults. The obvious method would be to
check each entry against the manual, however, probably over thinking
this, I wondered if the manual and my distribution (Debian Jessie) my
be different.


postconf -n or postconf -d is not working for you?

http://www.postfix.org/postconf.1.html
They work very well. But they do not tell me when and what options I may 
have added to my config which duplicate a default option. While such 
duplications are not disasters they make the config files that bit more 
complex than they need to be.


Actually I realized that I had a simple solution at hand in meld.

--
John Allen
KLaM
--
I just go lost in thought. It was unfamiliar territory.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SOLVED: Postfix configuration postconf

[John]

Surprisingly, I found that I had only six items that were duplicated.
One, a file location which I left as is following Wietse's  advice. The 
remainder I left in place as book marks for the future.


Thanks to both Wietse and Ben for their input.

--
John Allen
KLaM
--
we should be careful not to ascribe to malice what could equally be 
explained by incompetence.




smime.p7s
Description: S/MIME Cryptographic Signature

Postfix configuration settings inheritance for additional services in master.cf

[Igor Zinovik]

  Hello.

I'd like to ask how configuration directives are applied to
additional services that are specified in master.cf.


If main.cf contains:
...
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_local_domain = example.com

smtpd_helo_restrictions = permit_mynetworks
  permit_sasl_authenticated
  reject_non_fqdn_helo_hostname

Does these settings apply to my submission and SMTP over SSL services
that I configured in master.cf?

465 inet  n   -   n   -   -   smtpd
   -o syslog_name=postfix/ssl
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_tls_wrappermode=yes
...
submission inet n   -   n   -   -   smtpd
   -o syslog_name=postfix/submission
   -o smtpd_sasl_auth_enable=yes

Re: Postfix configuration settings inheritance for additional services in master.cf

[Wietse Venema]

Igor Zinovik:
 I'd like to ask how configuration directives are applied to
 additional services that are specified in master.cf.

See http://www.postfix.org/master.5.html

  -o name=value
 Override  the  named main.cf configuration parameter. The
 parameter value can refer to other  parameters  as  $name
 etc.,  just like in main.cf.  See postconf(5) for syntax.

See the manpage for the full text.

Wietse

postfix configuration

[Stefano Gatto]

Hi all
I'm trying to configure postfix 2.7.1 to protect internal mailing list with
the restriction classes as per
http://www.postfix.org/RESTRICTION_CLASS_README.html#internal
Example 
/etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
check_recipient_access hash:/etc/postfix/protected_destinations
...the usual stuff...

smtpd_restriction_classes = insiders_only
insiders_only = check_sender_access hash:/etc/postfix/insiders, reject

Everything works as expected, If a client not in insider.db  try to send a
mail with the list in filed to: the mail bounce back to sender.
The problem arise when someone send an email to a real mailbox in field TO:
and to the list in field CC: 
In that situation the mail server forwards the email to everyone in the
list.
Can someone help me to reconfigure postfix not to forward to the list
address even if is in the field CC:?
Tya Stefano

Re: postfix configuration

[Jeroen Geilman]

On 10/09/2013 10:03 PM, Stefano Gatto wrote:

Hi all
I'm trying to configure postfix 2.7.1 to protect internal mailing list with
the restriction classes as per
http://www.postfix.org/RESTRICTION_CLASS_README.html#internal
Example
/etc/postfix/main.cf:
 smtpd_recipient_restrictions =
 ...
 check_recipient_access hash:/etc/postfix/protected_destinations
 ...the usual stuff...

 smtpd_restriction_classes = insiders_only
 insiders_only = check_sender_access hash:/etc/postfix/insiders, reject

Everything works as expected, If a client not in insider.db  try to send a
mail with the list in filed to: the mail bounce back to sender.
The problem arise when someone send an email to a real mailbox in field TO:
and to the list in field CC:
In that situation the mail server forwards the email to everyone in the
list.


That's because a message may have many recipients, but only one sender.
Reverse the restriction class logic: FIRST check if any recipients are 
in your restricted list, and then check if the sender is in insiders.db, 
and allow it if it is.

This causes the sole recipient to be rejected, but not the message.

That is what should be happening with your setup too, but you don't show 
the full configuration as requested in the list welcome message, and I 
won't guess.



Can someone help me to reconfigure postfix not to forward to the list
address even if is in the field CC:?


A recipient is a recipient (is a recipient...); one is not more special 
than any other.


--
J.

Re: postfix configuration

[Noel Jones]

On 10/9/2013 3:03 PM, Stefano Gatto wrote:
 Hi all
 I'm trying to configure postfix 2.7.1 to protect internal mailing list with
 the restriction classes as per
 http://www.postfix.org/RESTRICTION_CLASS_README.html#internal
 Example 
 /etc/postfix/main.cf:
 smtpd_recipient_restrictions =
 ...
 check_recipient_access hash:/etc/postfix/protected_destinations
 ...the usual stuff...
 
 smtpd_restriction_classes = insiders_only
 insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
 
 Everything works as expected, If a client not in insider.db  try to send a
 mail with the list in filed to: the mail bounce back to sender.
 The problem arise when someone send an email to a real mailbox in field TO:
 and to the list in field CC: 
 In that situation the mail server forwards the email to everyone in the
 list.
 Can someone help me to reconfigure postfix not to forward to the list
 address even if is in the field CC:?
 Tya Stefano
 


Postfix never makes delivery decisions based on headers, so you
should recheck your evidence.

Note that a multi-recipient message that includes both banned and
permitted recipients will only block the banned recipients.  The
permitted recipients will still receive the message and the headers
may make it *appear* it was delivered to the banned recipients.

Also, you seem to use sender and client interchangeably above.
Maybe just a typo, but be sure you understand the difference.

If you need more help, you'll need to show us exactly what you've
configured and logs of the undesired behavior.
http://www.postfix.org/DEBUG_README.html#mail




  -- Noel Jones

need to purge clamav from postfix configuration

[David Benfell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

As near as I can tell debian's clamav is just broken. It keeps whining
about clamd.ctl and nothing I can find on the web fixes it.

So fine. It's broken. I want it gone.

I tried commenting out the lines in master.cf and main.cf. But now it
complains about connection refused on port 10026. So the clamav
configuration won't work and it won't stop getting in the way. I've
been going nuts with this for several hours and I'm tired.

Here is postconf -n:

address_verify_map = btree:$data_directory/verify_cache
alias_database = $alias_maps
alias_maps = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin; export PATH;
(echo cont; echo where) | gdb $daemon_directory/$process_name
$process_id 21 $config_directory/$process_name.$process_id.log 
sleep 5
fast_flush_domains = $relay_domains
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = no
in_flow_delay = 1s
inet_interfaces = 127.0.0.1, 10.8.0.1, 91.205.174.238
inet_protocols = ipv4
local_destination_concurrency_limit = 2
mail_owner = postfix
mailbox_command_maps = hash:/etc/postfix/mailbox_commands
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 20971520
mydestination = localhost, localhost.$mydomain, cybernude.org,
mail.cybernude.org, munich.cybernude.org, www.cybernude.org,
disunitedstates.com, mail.disunitedstates.com,
munich.disunitedstates.com, www.disunitedstates.com,
disunitedstates.org, mail.disunitedstates.org,
munich.disunitedstates.org, www.disunitedstates.org, greybeard95a.com,
mail.greybeard95a.com, munich.greybeard95a.com, www.greybeard95a.com,
n4rky.me, mail.n4rky.me, munich.n4rky.me, www.n4rky.me,
parts-unknown.org, mail.parts-unknown.org, munich.parts-unknown.org,
www.parts-unknown.org
mydomain = parts-unknown.org
myhostname = mail.parts-unknown.org
mynetworks = 10.8.0.0/16, 127.0.0.0/8
mynetworks_style = subnet
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:$config_directory/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = zen.spamhaus.org*3, b.barracudacentral.org*2,
bl.spameatingmonkey.net*2, dnsbl.ahbl.org*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_greet_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
relay_domains = *
sample_directory = /etc/postfix/sample
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_tls_key_file = /big/www/ssl/munich/munich.parts-unknown.org.key
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = permit_mynetworks,permit_sasl_authenticated
smtpd_peername_lookup = no
smtpd_recipient_restrictions =
permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client
zen.spamhaus.org,reject_rbl_client bl.spamcop.net
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = check_recipient_access
hash:/etc/postfix/restrict
smtpd_tls_auth_only = yes
smtpd_tls_cert_file =
/big/www/ssl/munich/munich.parts-unknown.org.concatenated.crt
smtpd_tls_loglevel = 1
smtpd_tls_security_level = none
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/var/lib/mailman/data/virtual-mailman

And here is postconf -M:

spamassassin unix -  n   n   -   -   pipe
user=nobody argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f
${sender} ${recipient}
587inet  n   -   n   -   -   smtpd -o
smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
scan   unix  -   -   n   -   16  smtp -o
smtp_send_xforward_command=yes
smtp   inet  n   -   n   -   1   postscreen
smtpd  pass  -   -   n   -   -   smtpd -o
content_filter=spamassassin -v
dnsblogunix  -   -   n   -   0   dnsblog
tlsproxy   unix  -   -   n   -   0   tlsproxy
submission inet  n   -   n   

Re: need to purge clamav from postfix configuration

[Wietse Venema]

David Benfell:
 As near as I can tell debian's clamav is just broken. It keeps whining
 about clamd.ctl and nothing I can find on the web fixes it.
 
 So fine. It's broken. I want it gone.
 
 I tried commenting out the lines in master.cf and main.cf. But now it
 complains about connection refused on port 10026.

Some messages still need to be filtered. To clear that flag:

# postsuper -r ALL

Wietse

Re: need to purge clamav from postfix configuration

[Scott Kitterman]

On Saturday, September 21, 2013 03:34:57 David Benfell wrote:
 Hi all,
 
 As near as I can tell debian's clamav is just broken. It keeps whining
 about clamd.ctl and nothing I can find on the web fixes it.

You didn't post your original configuration, so I don't know what your original 
problem was.  If you're using a Unix socket and having a Debian specific 
problem, it's probably a matter of the socket not being available in the 
chroot that postfix, on Debian, uses by default.  Assuming this was your 
original problem, there are three ways to solve it:

1.  Make the socket available in the chroot (/var/spool/postfix/).
2.  Take postfix out of the chroot.
3.  Using TCP sockets instead.

I use the Debian clamav packages every day.  I also maintain them for the 
distro.  If you are having problems, I encourage you to file bugs in the Debian 
BTS.  I do look at them and try to solve them.

Scott K

Re: need to purge clamav from postfix configuration

[DTNX Postmaster]

On Sep 21, 2013, at 16:36, Scott Kitterman post...@kitterman.com wrote:

 On Saturday, September 21, 2013 03:34:57 David Benfell wrote:
 Hi all,
 
 As near as I can tell debian's clamav is just broken. It keeps whining
 about clamd.ctl and nothing I can find on the web fixes it.
 
 You didn't post your original configuration, so I don't know what your 
 original 
 problem was.  If you're using a Unix socket and having a Debian specific 
 problem, it's probably a matter of the socket not being available in the 
 chroot that postfix, on Debian, uses by default.  Assuming this was your 
 original problem, there are three ways to solve it:
 
 1.  Make the socket available in the chroot (/var/spool/postfix/).
 2.  Take postfix out of the chroot.
 3.  Using TCP sockets instead.
 
 I use the Debian clamav packages every day.  I also maintain them for the 
 distro.  If you are having problems, I encourage you to file bugs in the 
 Debian 
 BTS.  I do look at them and try to solve them.

+1 on using Debian ClamAV packages without any problems. We use the 
milter package to integrate it with Postfix, using unix sockets.

The problem people generally run into with unix sockets is one of 
permissions. The milter socket needs to be stored inside the Postfix 
chroot, and be writable by both Postfix and the milter daemon.

Mvg,
Joni

Re: need to purge clamav from postfix configuration

[li...@rhsoft.net]

Am 21.09.2013 17:25, schrieb DTNX Postmaster:
 +1 on using Debian ClamAV packages without any problems. We use the 
 milter package to integrate it with Postfix, using unix sockets.
 
 The problem people generally run into with unix sockets is one of 
 permissions. The milter socket needs to be stored inside the Postfix 
 chroot, and be writable by both Postfix and the milter daemon

which leaves the question open why the Debian postfix-maintainer
insists in the *non upstream* chroot-default after years of most
problems reported here are caused by it?

Re: need to purge clamav from postfix configuration

[Scott Kitterman]

On Saturday, September 21, 2013 17:34:35 li...@rhsoft.net wrote:
 Am 21.09.2013 17:25, schrieb DTNX Postmaster:
  +1 on using Debian ClamAV packages without any problems. We use the
  milter package to integrate it with Postfix, using unix sockets.
  
  The problem people generally run into with unix sockets is one of
  permissions. The milter socket needs to be stored inside the Postfix
  chroot, and be writable by both Postfix and the milter daemon
 
 which leaves the question open why the Debian postfix-maintainer
 insists in the *non upstream* chroot-default after years of most
 problems reported here are caused by it?

That's a question best asked on a Debian specific channel.  Personally, I don't 
have any problems with it, it works fine for me.

Scott K

Re: need to purge clamav from postfix configuration

[David Benfell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2013 07:36 AM, Scott Kitterman wrote:
 On Saturday, September 21, 2013 03:34:57 David Benfell wrote:
 Hi all,
 
 As near as I can tell debian's clamav is just broken. It keeps
 whining about clamd.ctl and nothing I can find on the web fixes
 it.
 
 You didn't post your original configuration, so I don't know what
 your original problem was.  If you're using a Unix socket and
 having a Debian specific problem, it's probably a matter of the
 socket not being available in the chroot that postfix, on Debian,
 uses by default.  Assuming this was your original problem, there
 are three ways to solve it:
 
 1.  Make the socket available in the chroot (/var/spool/postfix/). 
 2.  Take postfix out of the chroot. 3.  Using TCP sockets instead.

The lines I had taken out in main.cf, based on something I found on
the web, are:

#content_filter = scan:127.0.0.1:10026
#receive_override_options = no_address_mappings

And out of master.cf are:

#127.0.0.1:10025 inet  n -   n   -   16  smtpd
   #-o content_filter=
   #-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
   #-o smtpd_helo_restrictions=
   #-o smtpd_client_restrictions=
   #-o smtpd_sender_restrictions=
   #-o smtpd_recipient_restrictions=permit_mynetworks,reject
   #-o mynetworks_style=host
   #-o smtpd_authorized_xforward_hosts=127.0.0.0/8

I think of the three choices you offer, I would prefer to take postfix
out of the chroot. Postfix's configuration is already far more
complicated than I can even begin to make any sense of, the
configuration, copied over from a hosed Arch installation (thanks
systemd upgrade), was not written for it (looking at
https://we.riseup.net/debian/authenticated-smtp it appears the
question becomes what else do I need to do to kill the chroot), and I
would prefer to move in the direction of simplicity.
 
 I use the Debian clamav packages every day.  I also maintain them
 for the distro.  If you are having problems, I encourage you to
 file bugs in the Debian BTS.  I do look at them and try to solve
 them.

If this were back in the 1970s or early 1980s, when I was a
programmer, I might be able to discern what is and is not a bug. The
world has moved quite a ways since then, often leaving me in a state
of fury, because what everybody else thinks is correct behavior I see
as absolutely broken. (And systemd on Arch is not the example I would
choose here: it may be a good idea but it's just not stable yet, it
obscures far too much, and it's a mistake for me to rely on it.)
There's no reconciling those worldviews. I can't tell a bug from
design behavior these days. I just want it to work so I can go back to
focusing on my Ph.D. program which is *not* technology related.

Thanks!

- -- 
David Benfell
see https://parts-unknown.org/node/2 if you don't understand the
attachment
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSPcL9AAoJEKrN0Ha7pkCO5LgP/09Bghza4wVq3/0ek13rMKuO
A3zNd1g3/0VIviQgzzeeRrOy8IYVxraqPZm2jP5yvmIgxAJVHv2o9xk9X+j/GLRO
XEcEuHHWcvFE4ersJgY+YOGbQaE1saFdFYpEdnIigSv+145i7pFzmQkX/tXiBf8/
GxmQRBYCCSb9Fj7xySSfEIdYhi5Vngru8qbuHGGKLgcR+PO/5XEZSVJzJVAUBGac
DxbGtRZav73NiCHnoVQpfd9TfFOohMe565KfRTtJDHlunXfrRxTQwtqMfRW5xeJb
fGGsT8QqX1pcs9QtfgjMARpRvapiIKZBxpGEuYlcnsxvMh4s3QSemMz3w2KxBRN9
LmwgrqlzfRXRg/aTYRT2V4Uk8P1ZjjUFCdOAkvfPZBVcXvwQQPqFSIRbVFZlb/BO
x65EBPOdGMGmC9Wl4+AZnwLyI+xkxcc0i89cLCS98JU+U8fdbObf+HXMO31DyGkr
Ed1qb6Wo/+zdZe5n1ZwOZc4DcRYf0mxuEudNe68yE1rrY3tY3/WmdJHzECM3O7kR
H7FpOzapHK7jDjhhrZ1vdE+owFOrttAvqVOVWZPIprqwDe4X8AljnfZygSY35uaG
Ygm6t6Bz8/yIzYJGpxFT+qaSA+ZemEgISboqhVBWf6WWofCfrle8BGRHVsHLZBXU
M8CSTUs57oC+255z1vRR
=mry2
-END PGP SIGNATURE-
attachment: dbenfell.vcf

Re: need to purge clamav from postfix configuration

[Scott Kitterman]

On Saturday, September 21, 2013 09:02:05 David Benfell wrote:
 On 09/21/2013 07:36 AM, Scott Kitterman wrote:
  On Saturday, September 21, 2013 03:34:57 David Benfell wrote:
  Hi all,
  
  As near as I can tell debian's clamav is just broken. It keeps
  whining about clamd.ctl and nothing I can find on the web fixes
  it.
  
  You didn't post your original configuration, so I don't know what
  your original problem was.  If you're using a Unix socket and
  having a Debian specific problem, it's probably a matter of the
  socket not being available in the chroot that postfix, on Debian,
  uses by default.  Assuming this was your original problem, there
  are three ways to solve it:
  
  1.  Make the socket available in the chroot (/var/spool/postfix/).
  2.  Take postfix out of the chroot. 3.  Using TCP sockets instead.
 
 The lines I had taken out in main.cf, based on something I found on
 the web, are:
 
 #content_filter = scan:127.0.0.1:10026
 #receive_override_options = no_address_mappings

What had you configured to listen on port 10026?  Personally, I use clamsmtp 
and amavisd-new (depending on if I'm just doing virus scanning or also doing 
content scanning for spam, etc.)

 And out of master.cf are:
 
 #127.0.0.1:10025 inet  n -   n   -   16  smtpd
#-o content_filter=
#-o
 receive_override_options=no_unknown_recipient_checks,no_header_body_checks
#-o smtpd_helo_restrictions=
#-o smtpd_client_restrictions=
#-o smtpd_sender_restrictions=
#-o smtpd_recipient_restrictions=permit_mynetworks,reject
#-o mynetworks_style=host
#-o smtpd_authorized_xforward_hosts=127.0.0.0/8
 
 I think of the three choices you offer, I would prefer to take postfix
 out of the chroot. Postfix's configuration is already far more
 complicated than I can even begin to make any sense of, the
 configuration, copied over from a hosed Arch installation (thanks
 systemd upgrade), was not written for it (looking at
 https://we.riseup.net/debian/authenticated-smtp it appears the
 question becomes what else do I need to do to kill the chroot), and I
 would prefer to move in the direction of simplicity.

The upstream master.cf is shipped in /usr/share/postfix (it's master.cf.dist).  
You can check it to verify which services should be removed from the chroot.

  I use the Debian clamav packages every day.  I also maintain them
  for the distro.  If you are having problems, I encourage you to
  file bugs in the Debian BTS.  I do look at them and try to solve
  them.
 
 If this were back in the 1970s or early 1980s, when I was a
 programmer, I might be able to discern what is and is not a bug. The
 world has moved quite a ways since then, often leaving me in a state
 of fury, because what everybody else thinks is correct behavior I see
 as absolutely broken. (And systemd on Arch is not the example I would
 choose here: it may be a good idea but it's just not stable yet, it
 obscures far too much, and it's a mistake for me to rely on it.)
 There's no reconciling those worldviews. I can't tell a bug from
 design behavior these days. I just want it to work so I can go back to
 focusing on my Ph.D. program which is *not* technology related.

I think this is likely a configuration issue and not a bug in any case.

Scott K

Re: need to purge clamav from postfix configuration

[DTNX Postmaster]

On Sep 21, 2013, at 18:02, David Benfell dbenf...@gmail.com wrote:

 On 09/21/2013 07:36 AM, Scott Kitterman wrote:
 On Saturday, September 21, 2013 03:34:57 David Benfell wrote:
 Hi all,
 
 As near as I can tell debian's clamav is just broken. It keeps
 whining about clamd.ctl and nothing I can find on the web fixes
 it.
 
 You didn't post your original configuration, so I don't know what
 your original problem was.  If you're using a Unix socket and
 having a Debian specific problem, it's probably a matter of the
 socket not being available in the chroot that postfix, on Debian,
 uses by default.  Assuming this was your original problem, there
 are three ways to solve it:
 
 1.  Make the socket available in the chroot (/var/spool/postfix/). 
 2.  Take postfix out of the chroot. 3.  Using TCP sockets instead.
 
 The lines I had taken out in main.cf, based on something I found on
 the web, are:
 
 #content_filter = scan:127.0.0.1:10026
 #receive_override_options = no_address_mappings
 
 And out of master.cf are:
 
 #127.0.0.1:10025 inet  n -   n   -   16  smtpd
   #-o content_filter=
   #-o
 receive_override_options=no_unknown_recipient_checks,no_header_body_checks
   #-o smtpd_helo_restrictions=
   #-o smtpd_client_restrictions=
   #-o smtpd_sender_restrictions=
   #-o smtpd_recipient_restrictions=permit_mynetworks,reject
   #-o mynetworks_style=host
   #-o smtpd_authorized_xforward_hosts=127.0.0.0/8
 
 I think of the three choices you offer, I would prefer to take postfix
 out of the chroot. Postfix's configuration is already far more
 complicated than I can even begin to make any sense of, the
 configuration, copied over from a hosed Arch installation (thanks
 systemd upgrade), was not written for it (looking at
 https://we.riseup.net/debian/authenticated-smtp it appears the
 question becomes what else do I need to do to kill the chroot), and I
 would prefer to move in the direction of simplicity.
 
 I use the Debian clamav packages every day.  I also maintain them
 for the distro.  If you are having problems, I encourage you to
 file bugs in the Debian BTS.  I do look at them and try to solve
 them.
 
 If this were back in the 1970s or early 1980s, when I was a
 programmer, I might be able to discern what is and is not a bug. The
 world has moved quite a ways since then, often leaving me in a state
 of fury, because what everybody else thinks is correct behavior I see
 as absolutely broken. (And systemd on Arch is not the example I would
 choose here: it may be a good idea but it's just not stable yet, it
 obscures far too much, and it's a mistake for me to rely on it.)
 There's no reconciling those worldviews. I can't tell a bug from
 design behavior these days. I just want it to work so I can go back to
 focusing on my Ph.D. program which is *not* technology related.

While the desire to have it 'just work' is recognizable, you cannot 
expect it to always do so if you copy bits and pieces from here to 
there without understanding what they actually do. Especially if you 
have copied an older configuration from a different distro that may 
have its own quirks.

We use Postfix on Debian in its 'stock' Debian chroot setup, with 
clamav-milter as the bridge between Postfix and clamd. This requires no 
configuration in 'master.cf' and only two lines in 'main.cf';

smtpd_milters = unix:/clamav/clamav-milter.ctl
milter_default_action = accept

Permissions is where it gets tricky, because the socket needs to be 
writable by both processes. As our own ClamAV setup is up for review 
anyway, I don't mind writing up a bit of a how-to for it that you can 
use to reimplement virus scanning with ClamAV, if you are still 
interested in doing so?

Mvg,
Joni

Re: need to purge clamav from postfix configuration

[David Benfell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2013 09:39 AM, DTNX Postmaster wrote:

 
 While the desire to have it 'just work' is recognizable, you cannot
  expect it to always do so if you copy bits and pieces from here to
  there without understanding what they actually do. Especially if
 you have copied an older configuration from a different distro that
 may have its own quirks.

Then we are very close to the point where I'll just have to turn
everything over to Google Apps. Because I am *never* going to
understand postfix configuration. This isn't even something that's
within a fuzzy or distant view, let alone just outside my grasp. It's
all complete magic to me.
 
 We use Postfix on Debian in its 'stock' Debian chroot setup, with 
 clamav-milter as the bridge between Postfix and clamd. This
 requires no configuration in 'master.cf' and only two lines in
 'main.cf';
 
 smtpd_milters = unix:/clamav/clamav-milter.ctl 
 milter_default_action = accept
 
 Permissions is where it gets tricky, because the socket needs to be
  writable by both processes. As our own ClamAV setup is up for
 review anyway, I don't mind writing up a bit of a how-to for it
 that you can use to reimplement virus scanning with ClamAV, if you
 are still interested in doing so?

At least within postfix, there is a very nice command to just fix the
permissions. (Did Wietse get tired of seeing that particular problem?)
I have no idea what they should be for clamd.ctl because, as near as I
can tell, it isn't a permanent file, so I can't even see it in the
emergency backup I did from a rescue system after the Arch upgrade
hosed my server (which is remote, by the way).

At this point, my first priority has to be just getting mail back up.
I've had a lot of these domains for a decade or more. I get a lot of
spam, hence the postscreen stuff, but I also get a lot of mail. Then,
maybe, I can think about reimplementing clamav.

- -- 
David Benfell
see https://parts-unknown.org/node/2 if you don't understand the
attachment
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSPfOpAAoJEKrN0Ha7pkCOupQQAJQWxZFBxViEmK9M2AJ2b5Ps
S/R/Q2ZiAzFZtXn+N0NxGBWH4bHlEM/UZ5BzRz/RVcdhyvJ+1BzZ88xGWEzteQH8
l0EjFx5QQEODdZ6JPGS17pS+zMtHzivrfq0l4Z9Oem3aYuoW+x0qmRBCqLMIztc5
MSJe/OOZKeZT7rA6zrLI5OaqtYU3w92UpKvFE9FTs1jXDyNgeSRFA94/V7c96+s+
0/pHu9NlIaF+zw5ljC1aVz7oZ20p+Pe8RUNOEt5OcmivaFMPvs+qVGcFe/CYBug0
lzGHD6IAAJbIqDPpF/mAr6oIfpvM2KeHImBeWDbETHj2eGQziiS58K1oXDOPEY8E
7XmcB/HQDalUtBYOsTSBJI5l7x44zWuxm9Ra39L+Daq81z8z4eoMvmmH34kGib7h
hKo9iSDV5VCFVUbw3cQYq1JQAVuWrz+2kNBLb+VTy+rmaZgkTlsS+wj6j2s/56dh
X16ze0giKBytOppip5zz885omLWyCgkvnBUWoCZVtoS+WGNHkumKEqp3FkvkEQ4n
A3VT2gecKh+qGngrCO3j+l6V12YqXYalf3PkPMtZ/hLYo9yC/fWbSBsSdNK6yX65
qK/g852qsOlyQ9OP5/DY0S2pMrkiSgjc3JssRpz4b3erb0ZKiVmNC9B4HaicY83a
fcfNCRNFPrcdaZdEu5QP
=33ef
-END PGP SIGNATURE-
attachment: dbenfell.vcf

Not Solved but Resolved, was Re: need to purge clamav from postfix configuration

[David Benfell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2013 08:34 AM, li...@rhsoft.net wrote:
 
 Am 21.09.2013 17:25, schrieb DTNX Postmaster:
 +1 on using Debian ClamAV packages without any problems. We use
 the milter package to integrate it with Postfix, using unix
 sockets.
 
 The problem people generally run into with unix sockets is one of
  permissions. The milter socket needs to be stored inside the
 Postfix chroot, and be writable by both Postfix and the milter
 daemon
 
 which leaves the question open why the Debian postfix-maintainer 
 insists in the *non upstream* chroot-default after years of most 
 problems reported here are caused by it?
 
 
My apologies. In part because my mail is not now getting sorted in its
normal way, I'm seeing some of these replies out of order.

There *is* a problem here. And actually my experience with systemd
suddenly becomes a little relevant. While I don't know of anyone
worshipping at the feet of the Debian Postfix maintainer, apparently
s/he is doing things that work for some people and not for others.

The same can be said, except that I *do* see people worshipping at the
feet of, the developer of pulseaudio and systemd. I think in general
distributions need to be more careful about adopting radical notions
that may not be necessary for things to actually work. (And while I
like keeping software up to date, a case can be made that many of the
recent changes in Arch Linux, which I've had to suddenly abandon,
leading to my dilemma with postfix on Debian, are changes for the sake
of change.)

Probably a bunch of people here have seen pulseaudio flame wars. I
don't mean to start anything of the sort here. But there are
occasionally problems where people developing something stop listening
to people who are actually trying to use it and who are running into
problems. The assumption seems to be it works for the developers,
therefore if you run into problems, it is *you* who are the idiot. (In
my line, I saw something very similar to this with
post-modernists--it's called intellectual bullying.)

That is, emphatically, not the case with postfix itself, but possibly
with the Debian maintainer of postfix. It is certainly also not the
only cause of flame wars, but I think it is one.

- From what I can see, the case for chrooting postfix is dubious at
best. Likewise, I was never satisfied with the case for wholesale
adoption of pulseaudio. In these cases, the problem is not so much
with the original software--there *does* need to be space for
innovation--but with the distribution(s).

And I think I'm now using a distribution that is, at least for me,
sabotaging postfix. Which means I'll need to use something else.
That's not a knock on postfix, but rather a critique of Debian on this
particular package.

- -- 
David Benfell
see https://parts-unknown.org/node/2 if you don't understand the
attachment
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSPf6gAAoJEKrN0Ha7pkCOSXEP/RLnPFN13AGykNNi2ktw40uU
pJl6eLqNcdMrOdNcQo8IAB4y7B9SkSYtLtrM7C6lLCNP9zL1Z9fxLiuZLw04bUEc
QBJp82L/2aZRmqiQs/S5jkTLagA+Xf6QSTFN4txMKz7VUWjkDhMq26xW1rIcHXlB
9uSmSWKIhFcvH9c4AjGyXDqr9E8H30H5AJQCpA7d99E9NHVhcoPd2DlTCDqiyqnm
NXtScLSxCPFcHlWDe8qYD7B2IUrMT/FJ9EU1MRSJez7cITUMHgQRsWRM/kZVaadc
SxiPqTLig11WgqFsjkatypWPxqYA2/IAQYU8ZdvQ7fNwb/EUfMMBT5lLrrTAAvhq
fvZP3D1nQ3x+ApFtZNI4Lu03wtFxUs2PmhWBEWz910zp8IG9OejYqeWnVjyk1DmA
oV1wsjHXvEsrqPYX7PCM6IjOzG9NITL0RObo+waa3RcmvfhrOqSDQa5zeRMnEpNJ
FoSRt18nLvG1JnBJnGvd/1L0HuFn2DU1AaPMHQw36QcGFz1bwKfnJNzIKdDG+qKM
0AcJ786WnqjlHNyfKGsxa3e54W6BJQ3XhtAg8S9CCN7FwEp47H/IShvxJpwswG6G
yO9KEVFBG5yBNkzoPutFmSi+KrUviGhPi8jS0Zqvn398VtRdG/Js0HmW/INY7Pqd
KyMmfu6ojPX/H5SMDYwt
=/gws
-END PGP SIGNATURE-
attachment: dbenfell.vcf

Re: need to purge clamav from postfix configuration

[DTNX Postmaster]

On Sep 21, 2013, at 21:29, David Benfell dbenf...@gmail.com wrote:

 On 09/21/2013 09:39 AM, DTNX Postmaster wrote:
 
 While the desire to have it 'just work' is recognizable, you cannot
 expect it to always do so if you copy bits and pieces from here to
 there without understanding what they actually do. Especially if
 you have copied an older configuration from a different distro that
 may have its own quirks.
 
 Then we are very close to the point where I'll just have to turn
 everything over to Google Apps. Because I am *never* going to
 understand postfix configuration. This isn't even something that's
 within a fuzzy or distant view, let alone just outside my grasp. It's
 all complete magic to me.

Outsourcing front-end processing to an external service is also an 
option; someone does the baseline stuff for you, like fending off bots 
and zombies and anything else that is obviously garbage, and then 
forwards the cleaned up feed to your server. This is how we operate our 
relay service, for example, and I bet there's a dozen others on this 
list that do something similar.

Also, Google Apps is pretty much paid now, is it not? Except up to ten 
users, if you're already an existing client?

You could also outsource the fix, and take over daily management again 
after that; there's a lot of consultants on this list as well. Or 
perhaps a basic hosting package somewhere that allows for some custom 
routing and whatnot, with a good filtering frontend, but that depends 
on what exactly your needs are?

 We use Postfix on Debian in its 'stock' Debian chroot setup, with 
 clamav-milter as the bridge between Postfix and clamd. This
 requires no configuration in 'master.cf' and only two lines in
 'main.cf';
 
 smtpd_milters = unix:/clamav/clamav-milter.ctl 
 milter_default_action = accept
 
 Permissions is where it gets tricky, because the socket needs to be
 writable by both processes. As our own ClamAV setup is up for
 review anyway, I don't mind writing up a bit of a how-to for it
 that you can use to reimplement virus scanning with ClamAV, if you
 are still interested in doing so?
 
 At least within postfix, there is a very nice command to just fix the
 permissions. (Did Wietse get tired of seeing that particular problem?)
 I have no idea what they should be for clamd.ctl because, as near as I
 can tell, it isn't a permanent file, so I can't even see it in the
 emergency backup I did from a rescue system after the Arch upgrade
 hosed my server (which is remote, by the way).
 
 At this point, my first priority has to be just getting mail back up.
 I've had a lot of these domains for a decade or more. I get a lot of
 spam, hence the postscreen stuff, but I also get a lot of mail. Then,
 maybe, I can think about reimplementing clamav.

Sounds like a decent plan, given the situation you found yourself in. 
Basics first.

Mvg,
Joni

Re: need to purge clamav from postfix configuration

[DTNX Postmaster]

On Sep 21, 2013, at 21:29, David Benfell dbenf...@gmail.com wrote:

 At least within postfix, there is a very nice command to just fix the
 permissions. (Did Wietse get tired of seeing that particular problem?)
 I have no idea what they should be for clamd.ctl because, as near as I
 can tell, it isn't a permanent file, so I can't even see it in the
 emergency backup I did from a rescue system after the Arch upgrade
 hosed my server (which is remote, by the way).

This is the socket, and it is or should be created by the ClamAV daemon 
on startup. Check your ClamAV configuration for details, on Debian the 
config files are in '/etc/clamav' by default. If there is no entry 
specifying the location, check the ClamAV docs for the default 
location, which is probably somewhere in '/var/run' or similar.

Mvg,
Joni

Re: need to purge clamav from postfix configuration

[Scott Kitterman]

On Saturday, September 21, 2013 23:50:00 DTNX Postmaster wrote:
 On Sep 21, 2013, at 21:29, David Benfell dbenf...@gmail.com wrote:
  At least within postfix, there is a very nice command to just fix the
  permissions. (Did Wietse get tired of seeing that particular problem?)
  I have no idea what they should be for clamd.ctl because, as near as I
  can tell, it isn't a permanent file, so I can't even see it in the
  emergency backup I did from a rescue system after the Arch upgrade
  hosed my server (which is remote, by the way).
 
 This is the socket, and it is or should be created by the ClamAV daemon
 on startup. Check your ClamAV configuration for details, on Debian the
 config files are in '/etc/clamav' by default. If there is no entry
 specifying the location, check the ClamAV docs for the default
 location, which is probably somewhere in '/var/run' or similar.

On Debian (and Ubuntu), as root (or using sudo depending on your system 
configuration) run dpkg-reconfigure clamav-base.  It will, among other things, 
ask you if you want a Unix socket or a TCP socket and what port to listen on.  
This is documented at the top of /etc/clamav/clamd.conf

Scott K

postfix configuration to a generic handler

[Tim Prepscius]

Hello,

This has probably been answered in some thread, however I'm having a
hard time finding it.
I'm reading through the documentation, and it is not clear how I would
fashion a configuration.



I would like to run postfix in the following fashion:

1.  post fix receives mail from anyuser@anydomain TO
someotheruser@anyotherdomain using SSL (PFS kind)

2.  after mail is received, my java or native handler program is
executed with the *entire* mail sent text via a
pipe/file/env/whatever.

It would be great if the mail never touched disk.  I could guarantee
the mail handler returns almost instantaneously.


3.  it would be nice, but not necessary, that if the above handler
program exits with an error, PostFix bounces with some generic
message.



But with the following additional needs:

1.  I don't want to make user accounts in the file system or actually
anywhere.  I don't want to write them down.
2.  I don't want to register the *real* domain name anywhere. (in any
file or account, etc)

Is this possible?


To reiterate:
Postfix would only do the protocol of receiving mail, mail would then
be sent to a handler program I have written.


Thank you very much for your time,

-tim

Re: postfix configuration to a generic handler

[Wietse Venema]

Tim Prepscius:
 Hello,
 
 This has probably been answered in some thread, however I'm having a
 hard time finding it.
 I'm reading through the documentation, and it is not clear how I would
 fashion a configuration.
 
 
 
 I would like to run postfix in the following fashion:
 
 1.  post fix receives mail from anyuser@anydomain TO
 someotheruser@anyotherdomain using SSL (PFS kind)
 
 2.  after mail is received, my java or native handler program is
 executed with the *entire* mail sent text via a
 pipe/file/env/whatever.
 
 It would be great if the mail never touched disk.  I could guarantee
 the mail handler returns almost instantaneously.
 
 
 3.  it would be nice, but not necessary, that if the above handler
 program exits with an error, PostFix bounces with some generic
 message.
 
 
 
 But with the following additional needs:
 
 1.  I don't want to make user accounts in the file system or actually
 anywhere.  I don't want to write them down.
 2.  I don't want to register the *real* domain name anywhere. (in any
 file or account, etc)
 
 Is this possible?
 
 To reiterate:
 Postfix would only do the protocol of receiving mail, mail would then
 be sent to a handler program I have written.

It's easy enough to send all mail into a pipe(8) command.

/etc/postfix/main.cf:
transport_maps = static:javapipe

/etc/postfix/master.cf:
javapipe  pipe 
user=xx flags=yy argv=/some/where/java-program $sender $recipient

However:

- How would Postfix know what domains to receive? It's a bad idea
to accept mail from any client to any destination. That would be
an open relay.

- How would Postfix know what recipients are valid? It's a bad idea
to accept-then-bounce mail for non-existent recipients.

Wietse

Re: postfix configuration to a generic handler

[Tim Prepscius]

oh wow, this worked, first time too.  jeeze.. that's awesome.

Thank you again, to answer your questions:

1.  I do in fact want to only accept mail from static ips and those
not on the block list.  But I figure there are configuration examples
for this.  I can spend the time to figure this out I think.  This has
to be standard config.

2.  I do in fact want to only accept mail for people in my database,
but I was hoping to as well provide an external program to return
0/1 for accept/deny for a recipient.

If you have suggestions on #2, I'll take them!!! ;-)

-tim

On 9/15/13, Wietse Venema wie...@porcupine.org wrote:
 Tim Prepscius:
 Hello,

 This has probably been answered in some thread, however I'm having a
 hard time finding it.
 I'm reading through the documentation, and it is not clear how I would
 fashion a configuration.



 I would like to run postfix in the following fashion:

 1.  post fix receives mail from anyuser@anydomain TO
 someotheruser@anyotherdomain using SSL (PFS kind)

 2.  after mail is received, my java or native handler program is
 executed with the *entire* mail sent text via a
 pipe/file/env/whatever.

 It would be great if the mail never touched disk.  I could guarantee
 the mail handler returns almost instantaneously.


 3.  it would be nice, but not necessary, that if the above handler
 program exits with an error, PostFix bounces with some generic
 message.



 But with the following additional needs:

 1.  I don't want to make user accounts in the file system or actually
 anywhere.  I don't want to write them down.
 2.  I don't want to register the *real* domain name anywhere. (in any
 file or account, etc)

 Is this possible?

 To reiterate:
 Postfix would only do the protocol of receiving mail, mail would then
 be sent to a handler program I have written.

 It's easy enough to send all mail into a pipe(8) command.

 /etc/postfix/main.cf:
 transport_maps = static:javapipe

 /etc/postfix/master.cf:
 javapipe  pipe
   user=xx flags=yy argv=/some/where/java-program $sender $recipient

 However:

 - How would Postfix know what domains to receive? It's a bad idea
 to accept mail from any client to any destination. That would be
 an open relay.

 - How would Postfix know what recipients are valid? It's a bad idea
 to accept-then-bounce mail for non-existent recipients.

   Wietse

Re: postfix configuration to a generic handler

[Wietse Venema]

Tim Prepscius:
 oh wow, this worked, first time too.  jeeze.. that's awesome.
 
 Thank you again, to answer your questions:
 
 1.  I do in fact want to only accept mail from static ips and those
 not on the block list.  But I figure there are configuration examples
 for this.  I can spend the time to figure this out I think.  This has
 to be standard config.

This is not a standard configuration. A standard configuration
accepts mail from anywhere to a restricted set of domains, and
accepts mail from a restricted set of clients to anywhere.

 2.  I do in fact want to only accept mail for people in my database,
 but I was hoping to as well provide an external program to return
 0/1 for accept/deny for a recipient.

Again, that is not a standard configuration.

 If you have suggestions on #2, I'll take them!!! ;-)

If you only accept mail from a restricted set of clients, then
this could be as simple as

mynetworks = list of networks and/or IP addresses
smtpd_recipient_restrictions = permit_mynetworks, reject

http://www.postfix.org/postconf.5.html#permit_mynetworks
http://www.postfix.org/postconf.5.html#mynetworks

As for validating recipients, I recommend that you use database
that Postfix can query.

virtual_mailbox_domains = example.com, example.net, ...
virtual_mailbox_maps = maptype:mapname
virtual_transport = javapipe

http://www.postfix.org/postconf.5.html#virtual_mailbox_domains
http://www.postfix.org/postconf.5.html#virtual_mailbox_maps
http://www.postfix.org/postconf.5.html#virtual_transport
http://www.postfix.org/ADDRESS_CLASS_README.html

where maptype:mapname returns a non-empty result when the recipient
is valid.  This can be hash:/file/name, mysql:/file/name,
ldap:/file/name, or any other database that Postfix supports.

http://www.postfix.org/msql_table.5.html
http://www.postfix.org/ldap_table.5.html
http://www.postfix.org/DATABASE_README.html

Wietse

 -tim
 
 On 9/15/13, Wietse Venema wie...@porcupine.org wrote:
  Tim Prepscius:
  Hello,
 
  This has probably been answered in some thread, however I'm having a
  hard time finding it.
  I'm reading through the documentation, and it is not clear how I would
  fashion a configuration.
 
 
 
  I would like to run postfix in the following fashion:
 
  1.  post fix receives mail from anyuser@anydomain TO
  someotheruser@anyotherdomain using SSL (PFS kind)
 
  2.  after mail is received, my java or native handler program is
  executed with the *entire* mail sent text via a
  pipe/file/env/whatever.
 
  It would be great if the mail never touched disk.  I could guarantee
  the mail handler returns almost instantaneously.
 
 
  3.  it would be nice, but not necessary, that if the above handler
  program exits with an error, PostFix bounces with some generic
  message.
 
 
 
  But with the following additional needs:
 
  1.  I don't want to make user accounts in the file system or actually
  anywhere.  I don't want to write them down.
  2.  I don't want to register the *real* domain name anywhere. (in any
  file or account, etc)
 
  Is this possible?
 
  To reiterate:
  Postfix would only do the protocol of receiving mail, mail would then
  be sent to a handler program I have written.
 
  It's easy enough to send all mail into a pipe(8) command.
 
  /etc/postfix/main.cf:
  transport_maps = static:javapipe
 
  /etc/postfix/master.cf:
  javapipe  pipe
  user=xx flags=yy argv=/some/where/java-program $sender $recipient
 
  However:
 
  - How would Postfix know what domains to receive? It's a bad idea
  to accept mail from any client to any destination. That would be
  an open relay.
 
  - How would Postfix know what recipients are valid? It's a bad idea
  to accept-then-bounce mail for non-existent recipients.
 
  Wietse
 
 

Re: postfix configuration to a generic handler

[Tim Prepscius]

ok so i have that working with the mysql db.
I'll eventually create a separate db with just one table.

I'm using a kludge from here:
http://stackoverflow.com/questions/4772229/configure-mail-server-to-receive-mail-from-any-domain

to get around specifying the domain:

virtual_mailbox_domains = pcre:/etc/postfix/virtual_domains.pcre

...

this postfix is great  lol.  the man pages are really intimidating
though. lol.

I really appreciate the advice,

-tim



On 9/15/13, Wietse Venema wie...@porcupine.org wrote:
 Tim Prepscius:
 oh wow, this worked, first time too.  jeeze.. that's awesome.

 Thank you again, to answer your questions:

 1.  I do in fact want to only accept mail from static ips and those
 not on the block list.  But I figure there are configuration examples
 for this.  I can spend the time to figure this out I think.  This has
 to be standard config.

 This is not a standard configuration. A standard configuration
 accepts mail from anywhere to a restricted set of domains, and
 accepts mail from a restricted set of clients to anywhere.

 2.  I do in fact want to only accept mail for people in my database,
 but I was hoping to as well provide an external program to return
 0/1 for accept/deny for a recipient.

 Again, that is not a standard configuration.

 If you have suggestions on #2, I'll take them!!! ;-)

 If you only accept mail from a restricted set of clients, then
 this could be as simple as

 mynetworks = list of networks and/or IP addresses
 smtpd_recipient_restrictions = permit_mynetworks, reject

 http://www.postfix.org/postconf.5.html#permit_mynetworks
 http://www.postfix.org/postconf.5.html#mynetworks

 As for validating recipients, I recommend that you use database
 that Postfix can query.

 virtual_mailbox_domains = example.com, example.net, ...
 virtual_mailbox_maps = maptype:mapname
 virtual_transport = javapipe

 http://www.postfix.org/postconf.5.html#virtual_mailbox_domains
 http://www.postfix.org/postconf.5.html#virtual_mailbox_maps
 http://www.postfix.org/postconf.5.html#virtual_transport
 http://www.postfix.org/ADDRESS_CLASS_README.html

 where maptype:mapname returns a non-empty result when the recipient
 is valid.  This can be hash:/file/name, mysql:/file/name,
 ldap:/file/name, or any other database that Postfix supports.

 http://www.postfix.org/msql_table.5.html
 http://www.postfix.org/ldap_table.5.html
 http://www.postfix.org/DATABASE_README.html

   Wietse

 -tim

 On 9/15/13, Wietse Venema wie...@porcupine.org wrote:
  Tim Prepscius:
  Hello,
 
  This has probably been answered in some thread, however I'm having a
  hard time finding it.
  I'm reading through the documentation, and it is not clear how I would
  fashion a configuration.
 
 
 
  I would like to run postfix in the following fashion:
 
  1.  post fix receives mail from anyuser@anydomain TO
  someotheruser@anyotherdomain using SSL (PFS kind)
 
  2.  after mail is received, my java or native handler program is
  executed with the *entire* mail sent text via a
  pipe/file/env/whatever.
 
  It would be great if the mail never touched disk.  I could guarantee
  the mail handler returns almost instantaneously.
 
 
  3.  it would be nice, but not necessary, that if the above handler
  program exits with an error, PostFix bounces with some generic
  message.
 
 
 
  But with the following additional needs:
 
  1.  I don't want to make user accounts in the file system or actually
  anywhere.  I don't want to write them down.
  2.  I don't want to register the *real* domain name anywhere. (in any
  file or account, etc)
 
  Is this possible?
 
  To reiterate:
  Postfix would only do the protocol of receiving mail, mail would then
  be sent to a handler program I have written.
 
  It's easy enough to send all mail into a pipe(8) command.
 
  /etc/postfix/main.cf:
  transport_maps = static:javapipe
 
  /etc/postfix/master.cf:
  javapipe  pipe
 user=xx flags=yy argv=/some/where/java-program $sender $recipient
 
  However:
 
  - How would Postfix know what domains to receive? It's a bad idea
  to accept mail from any client to any destination. That would be
  an open relay.
 
  - How would Postfix know what recipients are valid? It's a bad idea
  to accept-then-bounce mail for non-existent recipients.
 
 Wietse