Re: Postfix as Relay for Exchange, User overquota

[Wietse Venema]

stefan novak:
> thx, i've implemented that already for dovecot.
> 
> but i have the quota problem with users that are on our exchange
> server backend (it doesnt support this quota service)
> 
> is there a way to tell postfix that it accepts only mail on the
> frontend when the backend server (transport smtp destination) says
> that everything with this dst address is ok?
> a advanced "reject_unverified_recipient" method with the full header
> or something like that?

If you want Postfix to block mail for an over-quota EXCHANGE user,
then Postfix needs to find out whether an EXCHANGE user is over
quota. Does EXCHANGE support such queries? Dovecot does, though a
quota service.

Wietse

Re: Postfix as Relay for Exchange, User overquota

[stefan novak]

thx, i've implemented that already for dovecot.

but i have the quota problem with users that are on our exchange
server backend (it doesnt support this quota service)

is there a way to tell postfix that it accepts only mail on the
frontend when the backend server (transport smtp destination) says
that everything with this dst address is ok?
a advanced "reject_unverified_recipient" method with the full header
or something like that?

kind regards,
Stefan
___
www.epb.at - Your IT Partner in East Austria

Re: postfix upgrade-configuration

[Wietse Venema]

Postfix as distributed by me has never nagged about obsolete 'access'
files, and I suggest that any complaints about such behavior are
directed at the downstream maintainer who introduced that behavior.

Wietse

Re: Postfix as Relay for Exchange, User overquota

[Robert Schetterer]

Am 02.01.2018 um 19:59 schrieb stefan novak:
> Hello!
> 
> we are using Postfix as our MX Server for several mailservers, mostly
> dovecot. We have now implemented an exchange Server as well.
> 
> We are using the reject_unverified_recipient in combination with smtp
> transport-table to submit the E-mail back to the exchange Server.
> With our dovecot backends we can use the dovecot quota service in
> combination with the check_policy_service that Mails from full
> Mailboxes get rejected. How can i achieve this with our exchange
> backend? Now the Mails get bounced, which is not very nice :/
> 
> Is there a way to tell postfix to accept the E-Mail only when the
> exchange Server also wants to deliver it. Best will be when this works
> only on quota, since somietims its good when the postfix in front
> queue's the E-Mail. (Backend-Server reboot for patching...)
> 
> kind regards and sorry for my english ;)
> Stefan
> ___
> www.epb.at - Your IT Partner in East Austria
> 

try this

https://sys4.de/de/blog/2013/04/08/postfix-dovecot-mailbox-quota/

but be aware aliases etc may not have a mailbox quota, also the blog is
old ,things may have changed , you may should cover the used port by vpn
, ssltunnel etc

more

https://www.dovecot.org/list/dovecot/2016-July/104830.html
https://wiki2.dovecot.org/Quota


Best Regards
MfG Robert Schetterer

-- 
[*] 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: postfix upgrade-configuration

[@lbutlr]

On 2 Jan 2018, at 10:24, Wietse Venema wie...@porcupine.org> wrote:
> 
> @lbutlr:
>> On 1 Jan 2018, at 11:18, Wietse Venema wie...@porcupine.org> wrote:
>>> =20
>>> @lbutlr:
 On 31 Dec 2017, at 16:41, @lbutlr  wrote:
> Perhaps "are no longer part of the default Postfix install. If you =
>> are =3D
 not using them, they may be removed."?
>>> =20
>>> Per my previous email, Postfix 3.3 as distributed by me never reports
>>> the 'access' file as obsolete.
>> 
>> The current version of 3.3 does not. I was testing against the September =
>> version previously but have now installed the current build:
>> 
>> postfix 3.3-20171229:
>> /usr/local/etc/postfix/aliases /usr/local/etc/postfix/canonical
>> /usr/local/etc/postfix/generic /usr/local/etc/postfix/relocated
>> /usr/local/etc/postfix/transport /usr/local/etc/postfix/virtual
> 
> What is the above list of pathnames? Is that output from 'postconf
> upgrade-configuration'

Yes.

> I frequently install Postfix on a development machine, and I would
> certainly have noticed messages about an obsolete 'access' file

I no longer have the september build I was looking at to compare, though I 
think it was from freeBSD-ports. No matter, I use aliases and virtual and have 
removed the others since they contained only comments.

Unless there is a reason to eliminate virtual/aliases I'll keep them as long as 
I am delivering mail to users with a $HOME directory.

-- 
Hamburgers. The cornerstone of any nutritious breakfast.

Re: Postfix as Relay for Exchange, User overquota

[Wietse Venema]

stefan novak:
> Is there a way to tell postfix to accept the E-Mail only when the
> exchange Server also wants to deliver it.

Postfix uses the RCPT TO command to find out if a server is willing
to accept the message.

In the case of Dovecot, there is a way to find out if a user is
over quota (talk to the quota service).

Unless there is a way to ask the Exchange server about quota status,
Postfix cannot find out whether a user isoverr their mail quota.

Wietse

Postfix as Relay for Exchange, User overquota

[stefan novak]

Hello!

we are using Postfix as our MX Server for several mailservers, mostly
dovecot. We have now implemented an exchange Server as well.

We are using the reject_unverified_recipient in combination with smtp
transport-table to submit the E-mail back to the exchange Server.
With our dovecot backends we can use the dovecot quota service in
combination with the check_policy_service that Mails from full
Mailboxes get rejected. How can i achieve this with our exchange
backend? Now the Mails get bounced, which is not very nice :/

Is there a way to tell postfix to accept the E-Mail only when the
exchange Server also wants to deliver it. Best will be when this works
only on quota, since somietims its good when the postfix in front
queue's the E-Mail. (Backend-Server reboot for patching...)

kind regards and sorry for my english ;)
Stefan
___
www.epb.at - Your IT Partner in East Austria

Re: postfix upgrade-configuration

[Viktor Dukhovni]

> On Jan 2, 2018, at 12:24 PM, Wietse Venema  wrote:
> 
> I frequently install Postfix on a development machine, and I would
> certainly have noticed messages about an obsolete 'access' file
> (the access file on my development machine dates from 2005).

Indeed there have been very few additional "obsoleted" files in
config_directory:

postfix-2.6-20080207
+$config_directory/postfix-files:f:root:-:644:o
+$config_directory/postfix-script:f:root:-:755:o
+$config_directory/post-install:f:root:-:755:o

postfix-2.3-20051112
+$config_directory/generics:f:root:-:644:o

postfix-2.2-20050211
+$config_directory/generics:f:root:-:644:o

postfix-2.0.17-20040120
+$config_directory/cidr_table:f:root:-:644:o
+$config_directory/pcre_table:f:root:-:644:o
+$config_directory/regexp_table:f:root:-:644:o
+$config_directory/tcp_table:f:root:-:644:o

postfix-2.0.16-20031202
+$config_directory/install.cf:f:root:-:644:o
+$config_directory/postfix-script-sgid:f:root:-:755:o
+$config_directory/postfix-script-nosgid:f:root:-:755:o

The only remotely related change (which would not cause
the reported messages absent changes by the downstream
package maintainer) is a change to support multiple
instances in postfix-2.6-20090114:

-$config_directory/LICENSE:f:root:-:644
-$config_directory/TLS_LICENSE:f:root:-:644
-$config_directory/access:f:root:-:644:p
-$config_directory/aliases:f:root:-:644:p
-$config_directory/bounce.cf.default:f:root:-:644
-$config_directory/canonical:f:root:-:644:p
-$config_directory/generic:f:root:-:644:p
-$config_directory/header_checks:f:root:-:644:p
-$config_directory/main.cf.default:f:root:-:644
-$config_directory/makedefs.out:f:root:-:644
-$config_directory/relocated:f:root:-:644:p
-$config_directory/transport:f:root:-:644:p
-$config_directory/virtual:f:root:-:644:p
+$config_directory/LICENSE:f:root:-:644:1
+$config_directory/TLS_LICENSE:f:root:-:644:1
+$config_directory/access:f:root:-:644:p1
+$config_directory/aliases:f:root:-:644:p1
+$config_directory/bounce.cf.default:f:root:-:644:1
+$config_directory/canonical:f:root:-:644:p1
+$config_directory/generic:f:root:-:644:p1
+$config_directory/header_checks:f:root:-:644:p1
+$config_directory/main.cf.default:f:root:-:644:1
+$config_directory/makedefs.out:f:root:-:644:1
+$config_directory/relocated:f:root:-:644:p1
+$config_directory/transport:f:root:-:644:p1
+$config_directory/virtual:f:root:-:644:p1

The files in question are required only in the primary Postfix
instance.

-- 
-- 
Viktor.

Re: SENDEr-ACCESS exceptions

[Viktor Dukhovni]

> On Jan 2, 2018, at 12:19 PM, James B. Byrne  wrote:
> 
> The constantcontact.com domain was added to our sender_access file:
> 
> constantcontact.com   REJECT
> .constantcontact.com  REJECT

They are a largely legitimate bulk mailer that offers their services
to business customers.  They aren't always able to weed out customers
with dirty contact lists preëmptively.  So some of their traffic is
spam, but IIRC they drop and/or reeducate spamming customers.  YMMV.

I'd remove the rule and watch for unwanted traffic.  Report any abuse
you find to constantcontact, and see whether their response is adequate.

-- 
Viktor.

Re: postfix upgrade-configuration

[Wietse Venema]

@lbutlr:
> On 1 Jan 2018, at 11:18, Wietse Venema wie...@porcupine.org> wrote:
> >=20
> > @lbutlr:
> >> On 31 Dec 2017, at 16:41, @lbutlr  wrote:
> >>> Perhaps "are no longer part of the default Postfix install. If you =
> are =3D
> >> not using them, they may be removed."?
> >=20
> > Per my previous email, Postfix 3.3 as distributed by me never reports
> > the 'access' file as obsolete.
> 
> The current version of 3.3 does not. I was testing against the September =
> version previously but have now installed the current build:
> 
> postfix 3.3-20171229:
>  /usr/local/etc/postfix/aliases /usr/local/etc/postfix/canonical
>  /usr/local/etc/postfix/generic /usr/local/etc/postfix/relocated
>  /usr/local/etc/postfix/transport /usr/local/etc/postfix/virtual

What is the above list of pathnames? Is that output from 'postconf
upgrade-configuration' or some other command?

I frequently install Postfix on a development machine, and I would
certainly have noticed messages about an obsolete 'access' file
(the access file on my development machine dates from 2005).

Wietse

SENDEr-ACCESS exceptions

[James B. Byrne]

The constantcontact.com domain was added to our sender_access file:

constantcontact.com   REJECT
.constantcontact.com  REJECT

I must have done this but at some distant time in the past as I have
no recollection of doing so.

The situation is that now one of the professional organisations our
firm belongs to sends its newsletter via constantcontact.com.  I can
of course simply remove constantcontact.com from the block list. 
However, given that it is one of only two such entries I must have had
considerable provocation to add it to begin with.

My researches into the reputation of constantcontact.com does not
inspire confidence and tends to support the original decision. 
However, i may be compelled to allow their servers to connect to
deliver this particular organisation's monthly newsletter.

At the moment this is what happens:

This is what we see in our logs respecting constantcontact.com

smtpd[14594]: NOQUEUE: reject: RCPT from
ccm168.constantcontact.com[208.75.123.168]: 554 5.7.1
:

Sender address rejected: Access denied;
from=

to= proto=ESMTP

helo=


This indicates that we obtain a recipient address from the connection
before it is rejected.  Is their a method available to me to permit
one recipient address for this sender and block all the rest?  Is
there a better way to block all traffic from constantcontact.com
except for a specific recipent?


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: postfix upgrade-configuration

[@lbutlr]

On 1 Jan 2018, at 11:18, Wietse Venema wie...@porcupine.org> wrote:
> 
> @lbutlr:
>> On 31 Dec 2017, at 16:41, @lbutlr  wrote:
>>> Perhaps "are no longer part of the default Postfix install. If you are =
>> not using them, they may be removed."?
> 
> Per my previous email, Postfix 3.3 as distributed by me never reports
> the 'access' file as obsolete.

The current version of 3.3 does not. I was testing against the September 
version previously but have now installed the current build:

postfix 3.3-20171229:
 /usr/local/etc/postfix/aliases /usr/local/etc/postfix/canonical
 /usr/local/etc/postfix/generic /usr/local/etc/postfix/relocated
 /usr/local/etc/postfix/transport /usr/local/etc/postfix/virtual


-- 
WHO KNOWS WHAT EVIL LURKS IN THE HEART OF MEN?  The Death of Rats looked
up from the feast of potato. SQUEAK, he said. Death waved a hand
dismissively. WELL, YES, OBVIOUSLY *ME*, he said. I JUST WONDERED IF
THERE WAS ANYONE ELSE. --The Truth