Re: Sender dependent relay: Reject unknown senders

2017-07-21 Thread /dev/rob0 
On Fri, Jul 21, 2017 at 10:36:47PM +0200, Michael Büker wrote:
> sorry to bump myself here, but can anyone say if what I'd like is 
> even possible with postfix?

Of course.

> Should this be a feature request to the devs, maybe?

If so that would be done here also.

> On 18.07.2017 13:02, Michael Büker wrote:
> >Here's two alternate ideas of how I would like postfix to behave 
> >instead:
> >
> >1. Postfix should reject all mail that doesn't have a "From: "
> >identity associated with a relayhost in
> >sender_dependent_relayhost_maps.

You'd want a check_sender_access restriction lookup against the 
sender address list.

A nice way to keep such a list in one file would be a sqlite 
database.  For the restriction it would simply return "OK":

[ main.cf ]

[ ... ]
sender_dependent_relayhost_maps =
sqlite:/path/to/sender/relay-query
smtpd_sender_restrictions = check_sender_access
sqlite:/path/to/sender/access-query, reject

The sender_dependent_relayhost_maps query would use the same sqlite 
backend and same basic query, but the access query would have a 
"result_format = OK".

(You can use any lookup table type you want, I am merely making a 
suggestion in the interest of having all the data in one place.)

> >2. Postfix should *only* relay through one of the hosts in 
> >sender_dependent_relayhost_maps (or deliver locally), and *never* 
> >try to deliver directly to some external domain's MX.

That one could be done with "default_transport = error:not allowed" 
and replacing sender_dependent_relayhost_maps with 
sender_dependent_default_transport_maps.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: gratuitous failure on host address bits not zero

2017-07-21 Thread Stefan Monnier 
> I consider the netmask to be always primary - any bits set to the right of

Indeed, otherwise 192.168.0.0 would imply a /19


Stefan

Re: gratuitous failure on host address bits not zero

2017-07-21 Thread Matthew Patton 

>> since the user's intent is clearly obvious.

> What is the clearly obvious intent of 192.0.2.8/28 or 192.0.2.31/27? How
> should Postfix guess which part of the CIDR notation is wrong?

I consider the netmask to be always primary - any bits set to the right of the 
mask are inconsequential and should be tossed. If the netmask is specified 
wrong (won't parse) or is /0 then it's automatic /32. As improbable as anything 
to the left of /8 would be, I don't think it's justified to meddle.





If you wish to view the CPA Global group email disclaimer, please click 
here

Re: gratuitous failure on host address bits not zero

2017-07-21 Thread Bill Cole 

On 21 Jul 2017, at 15:50, Matthew Patton wrote:


since the user's intent is clearly obvious.


Not always.

What is the clearly obvious intent of 192.0.2.8/28 or 192.0.2.31/27? How 
should Postfix guess which part of the CIDR notation is wrong?

Re: gratuitous failure on host address bits not zero

2017-07-21 Thread Wietse Venema 
Matthew Patton:
> I love postfix but this struck me as a completely unnecessary failure mode.

Recent releases log this mistake as a warning:

postfix/postmap[2328]: warning: cidr map /tmp/dict, line 1:
non-null host address bits in "255.255.255.255/24", perhaps you
should use "255.255.255.0/24" instead: skipping this rule

postfix/smtpd[2355]: warning: mynetworks: non-null host address
bits in "255.255.255.255/24", perhaps you should use
"255.255.255.0/24" instead

postfix/smtpd[2355]: NOQUEUE: reject: RCPT from
tail.porcupine.org[168.100.189.3]: 451 4.3.0 :
Temporary lookup failure; from=<> to= proto=SMTP

The reason not to accept mail with this mistake in myetworks is
that it caused somone's system to become an open relay.

Wietse

Re: Sender dependent relay: Reject unknown senders

2017-07-21 Thread Michael Büker 

Hi list,

sorry to bump myself here, but can anyone say if what I'd like is even 
possible with postfix?


Should this be a feature request to the devs, maybe?

Thanks :)
Michael

On 18.07.2017 13:02, Michael Büker wrote:
Here's two alternate ideas of how I would like postfix to behave 
instead:


1. Postfix should reject all mail that doesn't have a "From: "
identity associated with a relayhost in
sender_dependent_relayhost_maps.

2. Postfix should *only* relay through one of the hosts in
sender_dependent_relayhost_maps (or deliver locally), and *never* try
to deliver directly to some external domain's MX.

How could I achieve this behavior?

Re: postdrop hangs until reboot: warning: mail_queue_enter: create file maildrop/...: Permission denied

2017-07-21 Thread Wietse Venema 
Vincent Lefevre:
[ Charset ISO-8859-1 converted... ]
> On 2017-07-20 06:55:33 -0400, Wietse Venema wrote:
> > Vincent Lefevre:
> > > Jul 20 11:18:11 zira postfix/postdrop[13399]: warning: mail_queue_enter: 
> > > create file maildrop/634289.13399: Permission denied
> > 
> > Someone goofed up while playing around as root.
> 
> I'm the only root, and I did nothing as root in the period.
> 
> > To fix, execute "postfix set-permissions".
> 
> I suppose that the permissions were correct because just a reboot
> solved the issue.

Perhaps. In any case, Postfix as released does not autonomously
change permissions. If permissions change, then ask down-stream 
distributors what they have in cron jobs or start-up scripts.

Wietse

gratuitous failure on host address bits not zero

2017-07-21 Thread Matthew Patton 
in ./src/util/cidr_match.c there is this bit of code:

240 /*
241  * Sanity check: all host address bits must be zero.
242  */
243 for (np = ip->net_bytes, mp = ip->mask_bytes;
244  np < ip->net_bytes + ip->addr_byte_count; np++, mp++) {
245 if (*np & ~(*mp)) {
246 mask_addr(ip->net_bytes, ip->addr_byte_count, 
ip->mask_shift);
247 if (inet_ntop(ip->addr_family, ip->net_bytes, hostaddr.buf,
248   sizeof(hostaddr.buf)) == 0)
249 msg_fatal("inet_ntop: %m");
250 vstring_sprintf(why ? why : (why = vstring_alloc(20)),
251 "non-null host address bits in \"%s/%s\", "
252 "perhaps you should use \"%s/%d\" instead",
253 pattern, mask, hostaddr.buf, 
ip->mask_shift);
254 return (why);
255 }
256 }

Causing Postfix daemons to fall over and die is ridiculous just because an IP 
(eg. mynetworks) and provided mask doesn't result in only zeros. Print a 
warning, maybe.


I don't see why cidr_match_parse() isn't written to be "liberal in what you 
accept, strict in what you return". It shouldn't care about stray bits during a 
compare, and should just memset(ip->mask_bytes, ...) and move on since the 
user's intent is clearly obvious.


I love postfix but this struck me as a completely unnecessary failure mode.



If you wish to view the CPA Global group email disclaimer, please click 
here

Re: postdrop hangs until reboot: warning: mail_queue_enter: create file maildrop/...: Permission denied

2017-07-21 Thread Vincent Lefevre 
On 2017-07-20 06:55:33 -0400, Wietse Venema wrote:
> Vincent Lefevre:
> > Jul 20 11:18:11 zira postfix/postdrop[13399]: warning: mail_queue_enter: 
> > create file maildrop/634289.13399: Permission denied
> 
> Someone goofed up while playing around as root.

I'm the only root, and I did nothing as root in the period.

> To fix, execute "postfix set-permissions".

I suppose that the permissions were correct because just a reboot
solved the issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: problem with mails

2017-07-21 Thread Wietse Venema 
Poliman - Serwis:
> 1) X-Postfix; connect to gle.com[69.172.201.153]:25: Connection timed out

Postfix makes a connection request and nothing happens.

> 2) host lotusbb.abus.de[62.153.75.197] said: 550 Requested action not
> taken: mailbox unavailable (in reply to RCPT TO command)

The recipient address does not exist.

> 3) 450 4.7.1 Client host rejected: cannot find your reverse hostname,

Your server's IP address has no PTR record.

Wietse

Re: Clear postscreen whitelist cache

2017-07-21 Thread Wietse Venema 
Scott Techlist:
> Is it possible to inspect or clear postscreen's whitelist cache?

This is not supported. You may read garbage, you may corrupt the
file.  If you're worried about what is in there, just delete the
file and do "postfix reload". It's just a performance cache.

Wietse

PATCH: LDAP: "unused parameter: start_tls=yes"?

2017-07-21 Thread Wietse Venema 
Ralf Hildebrandt:
> * Ralf Hildebrandt :
> > postconf complains:
> > /usr/sbin/postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused 
> > parameter: start_tls=yes
> > 
> > according to http://www.postfix.org/ldap_table.5.html
> 
> postfix-3.3-20170716 is complaining,
> postfix-3.3-20170611 is not complaining.
> 
> I suspect 
> 
> 20170617
> 
> Cleanup: the postconf command warns about unknown parameter
> names in a database configuration file, specified as an
> absolute pathname (for example, ldap:/path/to/file). This
> code was mostly written in January 2017, and it still is a
> partial implementation.  Files: postconf/postconf_dbms.c,
> postconf/Makefile.in, postconf/test66.ref.

Looks like a ton of parameters were added since I wrote this code.

Wietse

diff --exclude=man --exclude=html --exclude=README_FILES --exclude=INSTALL 
--exclude=.indent.pro --exclude=Makefile.in -r -bur 
/var/tmp/postfix-3.3-20170716/src/postconf/postconf_dbms.c ./postconf_dbms.c
--- /var/tmp/postfix-3.3-20170716/src/postconf/postconf_dbms.c  2017-06-18 
09:48:43.0 -0400
+++ ./postconf_dbms.c   2017-07-21 10:03:43.0 -0400
@@ -94,10 +94,13 @@
 "bind", "bind_dn", "bind_pw", "cache", "cache_expiry", "cache_size",
 "chase_referrals", "debuglevel", "dereference", "domain",
 "expansion_limit", "leaf_result_attribute", "query_filter",
-"recursion_limit", "result_attribute", "result_format", "scope",
-"search_base", "server_host", "server_port", "size_limit",
-"special_result_attribute", "terminal_result_attribute",
-"timeout", "version", 0,
+"recursion_limit", "result_attribute", "result_format",
+"sasl_authz_id", "sasl_mechs", "sasl_minssf", "sasl_realm",
+"scope", "search_base", "server_host", "server_port", "size_limit",
+"special_result_attribute", "start_tls", "terminal_result_attribute",
+"timeout", "tls_ca_cert_dir", "tls_ca_cert_file", "tls_cert",
+"tls_cipher_suite", "tls_key", "tls_random_file", "tls_require_cert",
+"version", 0,
 };
 
 /* See mysql_table(5). */

Re: smtp_pix_workaround_threshold_time not working correctly?

2017-07-21 Thread Wietse Venema 
Ralf Hildebrandt:
> In my log I found this:
> 
> Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
> workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25
> 

The "220 greeting" handler logs this when the server looks like
PIX, and was correct when PIX workarounds were always in effect.
The time threshold was added later, deep down in the guts of the
pipelined code, and the 220 greeting handler was not updated.

Wietse

Re: LDAP: "unused parameter: start_tls=yes"?

2017-07-21 Thread Ralf Hildebrandt 
* Ralf Hildebrandt :
> postconf complains:
> /usr/sbin/postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused 
> parameter: start_tls=yes
> 
> according to http://www.postfix.org/ldap_table.5.html

postfix-3.3-20170716 is complaining,
postfix-3.3-20170611 is not complaining.

I suspect 

20170617

Cleanup: the postconf command warns about unknown parameter
names in a database configuration file, specified as an
absolute pathname (for example, ldap:/path/to/file). This
code was mostly written in January 2017, and it still is a
partial implementation.  Files: postconf/postconf_dbms.c,
postconf/Makefile.in, postconf/test66.ref.

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: smtp_pix_workaround_threshold_time not working correctly?

2017-07-21 Thread Ralf Hildebrandt 
* Ralf Hildebrandt :
> In my log I found this:
> 
> Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
> workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25
> 
> According to 
> http://www.electric-spoon.com/doc/postfix/html/postconf.5.html#smtp_pix_workaround_maps
> 
> "By default, the workaround is turned off for mail that is queued for
> less than 500 seconds. In other words, the workaround is normally
> turned off for the first delivery attempt."
> 
> % fgrep 3xDK0Z6RBRz1Z1wy /var/log/mail.log
> 
> Jul 21 07:22:54 mail-cvk postfix/smtpd[5374]: 3xDK0Z6RBRz1Z1wy: 
> client=s-mx14-ht01.charite.de[10.32.37.105]
> ...
> Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
> workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25
> Jul 21 07:23:10 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: 
> to=, relay=mail.unimed.de[62.154.176.144]:25, delay=16, 
> delays=15/0/0.06/1.2, dsn=2.0.0, status=sent (250 Ok: queued as B51D41068C5)
> 
> Jul 21 07:23:10 mail-cvk postfix/qmgr[7149]: 3xDK0Z6RBRz1Z1wy: removed
> 
> That's 16s, why were the PIX workarounds triggered anyway?
> 
> Another:
> Jul 21 08:02:48 mail-cvk postfix/smtpd[10518]: 3xDKtc5hRMz1Z2wL: 
> client=s-mx14-ht01.charite.de[10.32.37.105]
> ...
> Jul 21 08:02:52 mail-cvk postfix/smtp[8678]: 3xDKtc5hRMz1Z2wL: enabling PIX 
> workarounds: disable_esmtp delay_dotcrlf for imh.rsys2.net[12.130.135.43]:25
> Jul 21 08:02:53 mail-cvk postfix/smtp[8678]: 3xDKtc5hRMz1Z2wL: 
> to=, 
> relay=imh.rsys2.net[12.130.135.43]:25, delay=6.5, delays=5/0/0.55/0.93, 
> dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 549AF1219F4)
> Jul 21 08:02:53 mail-cvk postfix/qmgr[7149]: 3xDKtc5hRMz1Z2wL: removed
> 
> That's 6s. 
> 
> Is the "PIX state" cached?
> 
> # postconf -n|fgrep pix
> smtp_pix_workarounds = delay_dotcrlf

Changed this just that moment, was set to the default before.

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

LDAP: "unused parameter: start_tls=yes"?

2017-07-21 Thread Ralf Hildebrandt 
postconf complains:
/usr/sbin/postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused 
parameter: start_tls=yes

according to http://www.postfix.org/ldap_table.5.html

STARTTLS can be turned on with the start_tls parameter:
   start_tls = yes
Both forms require LDAP protocol version 3, which has to be set explicitly with:
   version = 3

I'm using:

=== snip ===
server_host = 10.28.0.31
  10.28.0.32
search_base = dc=laborberlin,dc=intern
version = 3

bind_dn = CN=somecn 
bind_pw = secret

query_filter = (proxyAddresses=smtp:%s)
result_attribute = mail

start_tls = yes
=== snip ===

smtp_pix_workaround_threshold_time not working correctly?

2017-07-21 Thread Ralf Hildebrandt 
In my log I found this:

Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25

According to 
http://www.electric-spoon.com/doc/postfix/html/postconf.5.html#smtp_pix_workaround_maps

"By default, the workaround is turned off for mail that is queued for
less than 500 seconds. In other words, the workaround is normally
turned off for the first delivery attempt."

% fgrep 3xDK0Z6RBRz1Z1wy /var/log/mail.log

Jul 21 07:22:54 mail-cvk postfix/smtpd[5374]: 3xDK0Z6RBRz1Z1wy: 
client=s-mx14-ht01.charite.de[10.32.37.105]
...
Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25
Jul 21 07:23:10 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: 
to=, relay=mail.unimed.de[62.154.176.144]:25, delay=16, 
delays=15/0/0.06/1.2, dsn=2.0.0, status=sent (250 Ok: queued as B51D41068C5)

Jul 21 07:23:10 mail-cvk postfix/qmgr[7149]: 3xDK0Z6RBRz1Z1wy: removed

That's 16s, why were the PIX workarounds triggered anyway?

Another:
Jul 21 08:02:48 mail-cvk postfix/smtpd[10518]: 3xDKtc5hRMz1Z2wL: 
client=s-mx14-ht01.charite.de[10.32.37.105]
...
Jul 21 08:02:52 mail-cvk postfix/smtp[8678]: 3xDKtc5hRMz1Z2wL: enabling PIX 
workarounds: disable_esmtp delay_dotcrlf for imh.rsys2.net[12.130.135.43]:25
Jul 21 08:02:53 mail-cvk postfix/smtp[8678]: 3xDKtc5hRMz1Z2wL: 
to=, 
relay=imh.rsys2.net[12.130.135.43]:25, delay=6.5, delays=5/0/0.55/0.93, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 549AF1219F4)
Jul 21 08:02:53 mail-cvk postfix/qmgr[7149]: 3xDKtc5hRMz1Z2wL: removed

That's 6s. 

Is the "PIX state" cached?

# postconf -n|fgrep pix
smtp_pix_workarounds = delay_dotcrlf

# postconf -d mail_version
mail_version = 3.2-20170122