transport table ignored

[JB]

Hello to all you postfix gurus. I'm running into a nasty problem (at 
least for me.) I would be grateful for any help with this.


I have a setup with postfix that receives mail for a number of virtual 
domains, runs it through spam checks, and reinjects it back into post 
fix for final delivery. Once upon a time, my transport table entries 
were used but now they seem to be completely ignored. It's driving me 
nuts and I cannot figure out why this is happening. All I'm trying to do 
is take a set of domains previously virtually hosted and forward them to 
a new mail server during the DNS propagation delay period without 
breaking the previous configuration which still works for one virtual 
domain that will remain and will continue to deliver male locally using 
the virtual LDA.


I keep getting: "Recipient address rejected: User unknown in table>" where  depends on my configuration and I have 
tried many. I don't want any recipient address checking or validation or 
delivery for these domains. I want transport to take over before those 
users are rejected...or I want to allow postfix to accept mail for all 
the users and then let the destination MTA handle user address 
verification. Either way would be fine.


My transport looks like:
virtual-domain.comvirtual:
forward-domain.comsmtp:[###.###.###.###]

I have placed forward-domain.com into the relay_domains
I have left virtual-domain.com in virtual_mailbox_domains


Here are relevant parts of my master.cf:
smtpinetn   -   n   -   - smtpd
-o smtpd_proxy_filter=127.0.0.1:10024
-o smtpd_client_connection_count_limit=10
.
rewrite unix-   -   n   -   - trivial-rewrite
rewrite2unix-   -   n   -   - trivial-rewrite
local   unix-   n   n   -   - local
virtual unix-   n   n   -   - virtual
anvil unix  -   -   n   -   1   anvil
localhost:10025 inetn   -   n   -   - smtpd
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=
-o mynetworks=127.0.0.0/8
-o receive_override_options=no_unknown_recipient_checks
-o smtpd_restriction_classes=
maildrop  unix  -   n   n   -   -   pipe
  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}


My main.cf smtpd_recipient_restrictions looks like:
smtpd_recipient_restrictions =
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
check_recipient_access mysql:/etc/postfix/pre_recipient.cf
check_sender_access mysql:/etc/postfix/pre_sender.cf
permit_mynetworks,
permit_tls_all_clientcerts,
permit_sasl_authenticated,
check_client_access hash:/etc/postfix/pop-before-smtp
reject_unauth_destination,
check_sender_access mysql:/etc/postfix/sender_access.cf
check_client_access mysql:/etc/postfix/client_access.cf
check_recipient_access mysql:/etc/postfix/recipient_access.cf
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unauth_pipelining,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client dnsbl.njabl.org,
reject_rhsbl_sender dsn.rfc-ignorant.org,
reject_unlisted_recipient,
permit

Re: collate.pl

[Robert Dahlem]

Hi,

On 23.08.2016 18:44, Viktor Dukhovni wrote:

> A more general approach may be to replace "_slow" with "/slow" and
> ignore any additional / delimited components between the instance
> name and the program name.  That would require you to set a syslog_name
> along the lines of postfix-sec/slow or postfix-sec/submission, ...
> 
> and the RE then becomes (untested):
> 
> my $instre = qr{(?x)   # Ignore whitespace and comments
>\A  # Absolute line start
>(?:\S+ \s+){3}  # Timestamp, adjust for other time formats
>\S+ \s+ # Hostname
>(postfix(?:-[^/\s]+)?)  # Capture instance name stopping before first 
> '/'
>(?:/\S+)*   # Optional non-captured '/'-delimited 
> qualifiers
>/   # Final '/' before the daemon program name
>};
> 

I just wanted to report that this works great. I now have

faster unix - - y - - smtp
-o syslog_name=postfix/faster
slower unix - - y - - smtp
-o syslog_name=postfix/slower
# Re-Injection from Amavis
localhost:10025 inet n - y - - smtpd -o LOTS_OF_STUFF
-o syslog_name=postfix/10025

and it happily keeps things together:

 postfix/smtpd[29227]: connect from ...
 postfix/smtpd[29227]: 3CBF336A259: client=...
 postfix/cleanup[6001]: 3CBF336A259: prepend: header From: ...
 postfix/cleanup[6001]: 3CBF336A259: message-id=...
 postfix/qmgr[4757]: 3CBF336A259: from=...
 postfix/smtpd[29227]: disconnect from ...
 postfix/smtp[6046]: 3CBF336A259: to=...
 postfix/qmgr[4757]: 3CBF336A259: removed

 postfix/10025/smtpd[6075]: connect from localhost[127.0.0.1]
 postfix/10025/smtpd[6075]: B637D36A25A: client=...
 postfix/cleanup[6001]: B637D36A25A: message-id=...
 postfix/qmgr[4757]: B637D36A25A: from=...
 postfix/10025/smtpd[6075]: disconnect from ...
 postfix/slower/smtp[6077]: Trusted TLS connection ...
 postfix/slower/smtp[6077]: B637D36A25A: to=...
 postfix/qmgr[4757]: B637D36A25A: removed

Because it does no harm to anything existing I propose that attached
patch gets into the distribution.

Kind regards,
Robert
--- collate.pl.orig 2016-08-23 17:35:19.0 +0200
+++ collate.pl  2016-08-29 11:42:51.0 +0200
@@ -10,7 +10,9 @@
\A  # Absolute line start
(?:\S+ \s+){3}  # Timestamp, adjust for other time formats
\S+ \s+ # Hostname
-   (postfix(?:-\S+)?)/ # postfix instance
+   (postfix(?:-[^/\s]+)?)  # Capture instance name stopping before first 
'/'
+   (?:/\S+)*   # Optional non-captured '/'-delimited qualifiers
+   /
};
 
 my $cmdpidre = qr{(?x)

Re: collate.pl

[Wietse Venema]

Robert Dahlem:
> Because it does no harm to anything existing I propose that attached
> patch gets into the distribution.

It works with multi-instance names. What is the result for the stock
master.cf file, which has entries as shown below?

submission inet n   -   n   -   -   smtpd
   -o syslog_name=postfix/submission
   ...
smtps inet  n   -   n   -   -   smtpd
   -o syslog_name=postfix/smtps
   ...

This logs process names as: postfix/submission/smtpd, postfix/smtps/smtpd.

Sorry, I don't have time to parse the script.

Wietse

Re: transport table ignored

[Wietse Venema]

JB:
> I keep getting: "Recipient address rejected: User unknown in  table>" where  depends on my configuration and I have 
> tried many.

You need to read http://www.postfix.org/ADDRESS_CLASS_README.html
which explains exactly what causes that error message.

> I don't want any recipient address checking or validation or 

In that case you should not be using Postfix.

Wietse

Postfix stable release 3.1.2 and legacy release 3.0.6

[Wietse Venema]

[An on-line version of this announcement will be available at
http://www.postfix.org/announcements/postfix-3.1.2.html]

Postfix stable release 3.1.2 is available, as well as legacy release
3.0.6.

Fixed with Postfix 3.1.2:

  * Changes to make Postfix build with OpenSSL 1.1.0.

Fixed with Postfix 3.1.2 and 3.0.6:

  * The makedefs script ignored readme_directory=pathname overrides.
Fix by Todd C. Olson.

  * The tls_session_ticket_cipher documentation says that the default
cipher for TLS session tickets is aes-256-cbc, but the implemented
default was aes-128-cbc. Note that TLS session ticket keys are
rotated after 1/2 hour, to limit the impact of attacks on session
ticket keys.

You can find the updated Postfix source code at the mirrors listed
at http://www.postfix.org/.

Wietse

Re: collate.pl

[/dev/rob0]

On Mon, Aug 29, 2016 at 09:36:44AM -0400, Wietse Venema wrote:
> Robert Dahlem:
> > Because it does no harm to anything existing I propose that 
> > attached patch gets into the distribution.
> 
> It works with multi-instance names. What is the result for the 
> stock master.cf file, which has entries as shown below?
> 
> submission inet n   -   n   -   -   smtpd
>-o syslog_name=postfix/submission
>...
> smtps inet  n   -   n   -   -   smtpd
>-o syslog_name=postfix/smtps
>...
> 
> This logs process names as: postfix/submission/smtpd, 
> postfix/smtps/smtpd.

Just a thought, take it or leave it: perhaps those examples should
be changed to:

> submission inet n   -   n   -   -   smtpd
>-o syslog_name=$syslog_name/submission
>...
> smtps inet  n   -   n   -   -   smtpd
>-o syslog_name=$syslog_name/smtps
>...

Ugly, but it would work with multiple instance names.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: collate.pl

[Robert Dahlem]

Hi,

On 29.08.2016 15:36, Wietse Venema wrote:

>> Because it does no harm to anything existing I propose that attached
>> patch gets into the distribution.

> It works with multi-instance names. What is the result for the stock
> master.cf file, which has entries as shown below?
> 
> submission inet n   -   n   -   -   smtpd
>-o syslog_name=postfix/submission
>...
> smtps inet  n   -   n   -   -   smtpd
>-o syslog_name=postfix/smtps
>...

> This logs process names as: postfix/submission/smtpd, postfix/smtps/smtpd.
> 
> Sorry, I don't have time to parse the script.

This makes collate.pl with the proposed patch put
postfix/submission/smtpd
postfix/smtps/smtpd
in the same block as for example
postfix/cleanup
postfix/qmgr
postfix/smtp
which is exactly the intended behavior.

There is a potential problem with multiple instances: $syslog_name
defaults to $multi_instance_name. You need to pay attention to change
this in /etc/postfix-sec/master.cf too.

Unfortunately, /dev/rob0's proposol to use
"syslog_name=$syslog_name/submission" results in
warning: unreasonable macro call nesting: "syslog_name"

Kind regards,
Robert

Re: collate.pl

[Wietse Venema]

/dev/rob0:
> On Mon, Aug 29, 2016 at 09:36:44AM -0400, Wietse Venema wrote:
> > Robert Dahlem:
> > > Because it does no harm to anything existing I propose that 
> > > attached patch gets into the distribution.
> > 
> > It works with multi-instance names. What is the result for the 
> > stock master.cf file, which has entries as shown below?
> > 
> > submission inet n   -   n   -   -   smtpd
> >-o syslog_name=postfix/submission
> >...
> > smtps inet  n   -   n   -   -   smtpd
> >-o syslog_name=postfix/smtps
> >...
> > 
> > This logs process names as: postfix/submission/smtpd, 
> > postfix/smtps/smtpd.
> 
> Just a thought, take it or leave it: perhaps those examples should
> be changed to:
> 
> > submission inet n   -   n   -   -   smtpd
> >-o syslog_name=$syslog_name/submission
> >...
> > smtps inet  n   -   n   -   -   smtpd
> >-o syslog_name=$syslog_name/smtps
> >...
> 
> Ugly, but it would work with multiple instance names.

I think that would result in an "unreasonable macro call nesting"
error, because $name expansion is recursive.

Wietse

Re: collate.pl

[Robert Dahlem]

Hi,

On 29.08.2016 16:41, Robert Dahlem wrote:

> There is a potential problem with multiple instances: $syslog_name
> defaults to $multi_instance_name. You need to pay attention to change
> this in /etc/postfix-sec/master.cf too.
> 
> Unfortunately, /dev/rob0's proposol to use
> "syslog_name=$syslog_name/submission" results in
>   warning: unreasonable macro call nesting: "syslog_name"

I do not know the implications of the following: $multi_instance_name
defaults to "". If it would default to "postfix" then

-o syslog_name=$multi_instance_name/submission

could be the solution.

Kind regards,
Robert

Re: Postfix stable release 3.1.2 and legacy release 3.0.6

[Quanah Gibson-Mount]

--On Monday, August 29, 2016 10:40 AM -0400 Wietse Venema 
 wrote:



[An on-line version of this announcement will be available at
http://www.postfix.org/announcements/postfix-3.1.2.html]


Are there any plans to add the 20160730-postscreen patch to future 2.11.x 
and 3.x releases?


Thanks,
Quanah

--

Quanah Gibson-Mount

Re: collate.pl

[Viktor Dukhovni]

On Mon, Aug 29, 2016 at 09:36:44AM -0400, Wietse Venema wrote:

> Robert Dahlem:
> > Because it does no harm to anything existing I propose that attached
> > patch gets into the distribution.
> 
> It works with multi-instance names. What is the result for the stock
> master.cf file, which has entries as shown below?
> 
> submission inet n   -   n   -   -   smtpd
>-o syslog_name=postfix/submission
>...
> smtps inet  n   -   n   -   -   smtpd
>-o syslog_name=postfix/smtps
>...

The patch correctly groups these with the plain "postfix/" names
below:

> This logs process names as: postfix/submission/smtpd, postfix/smtps/smtpd.
> 
> Sorry, I don't have time to parse the script.

Provided that users avoid more exotic forms of secondary service
instance syslog_name which are not of the form
/, the collate script will figure
out that these secondary service instances are associated with the
same base Postfix instance.

Given that the OP has tested the suggested (more general second
form of the) regexp, I think it can go into the bundled auxiliary
script.

Perhaps I should attempt to auto-detect the time stamp format?
That's the main wart that prevents the script from being more
broadly applicable.

Apart from ISO date/time and the traditional syslog format,
are there any other forms in wide use?

-- 
Viktor.

Trouble relaying email from Dovecot through postfix to another mail server after putting in client restrictions

[Scott W. Sander]

I set up a internal postfix + dovecot server running on Ubuntu 14.04.5 a
few months ago.  I used the guide at the following link in order to get it
set up:

http://www.binarytides.com/install-postfix-dovecot-debian/

Just last week, I noticed that the server was accepting mail from basically
anything (though relay was configured to be more restricted).  I wanted it
to act more like Microsoft Exchange 2010 where authenticated mail clients
can connect and relay mail but unauthenticated clients are added to a
"receive connector" (Exchange term) by IP address and cannot even
successfully start sending SMTP commands unless they are in that list.

I did some research and reconfigured the client, HELO, and relay
restrictions.  My application servers that use postfix to relay mail are
still able to deliver the mail to both dovecot mailboxes and another domain
hosted on Microsoft Exchange without issue, but now dovecot clients are not
able to relay mail to Microsoft Exchange.

Here is the exact error message that is received by the mail client:

---

Server error: '554 5.7.1 : Client
host rejected: Access denied'

---

I know that this error is caused by the smptd_client_restrictions parameter
and not smptd_relay_restrictions.  Is there a way I can whitelist clients
that authenticated to dovecot via IMAP in postfix as well as other
application servers that are currently whitelisted by IP address?  I
thought the permit_sasl_authenticated entry in smtpd_client_restrictions
would have solved the issue, but it doesn't seem to.

Here is postconf -n:

---

user@appserver4:~$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
debug_peer_level = 1
debug_peer_list = domain.com
inet_interfaces = all
inet_protocols = all
lmtp_tls_security_level = none
mailbox_size_limit = 0
mydestination = appserver4.subdomain.domain.com, localhost.domain.com,
localhost, mail.domain.test
myhostname = mail.domain.test
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 10.253.254.225
10.254.254.225 10.254.254.226 10.254.254.171 10.254.254.172
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relay_domains = domain.com
relayhost = [exchangefe01.subdomain.domain.com]
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = aNULL, MD5, DES, ADH, RC4
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = aNULL, MD5, DES, ADH, RC4
smtp_tls_note_starttls_offer = yes
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1
smtp_tls_security_level = encrypt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_client_connection_rate_limit = 1000
smtpd_client_message_rate_limit = 1000
smtpd_client_new_tls_session_rate_limit = 1000
smtpd_client_port_logging = yes
smtpd_client_recipient_rate_limit = 3000
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname
smtpd_recipient_limit = 3000
smtpd_reject_unlisted_sender = no
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unverified_recipient, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/apps4_combined.pem
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = aNULL, MD5, DES, ADH, RC4
smtpd_tls_key_file = /etc/ssl/private/apps4_key.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5, DES, ADH, RC4
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
virtual_transport = lmtp:unix:private/dovecot-lmtp

Re: transport table ignored

[Jared Brokaw]

On Mon, Aug 29, 2016 at 7:39 AM, Wietse Venema  wrote:

> JB:
> > I keep getting: "Recipient address rejected: User unknown in  > table>" where  depends on my configuration and I have
> > tried many.
>
> You need to read http://www.postfix.org/ADDRESS_CLASS_README.html
> which explains exactly what causes that error message.
>

Interesting, I did read that before, but apparently I missed the part where
I have leave relay_recipient_maps empty to make it work. Seems to be
working as expected now.


>
> > I don't want any recipient address checking or validation or
>
> In that case you should not be using Postfix.
>

I meant I do not necessarily need/want recipient validation on the relay,
just on the final destination for the time being. I don't want to have
define every single user that will be receiving email on both the relay and
on the final destination. It is only temporary after all.

Re: Postfix stable release 3.1.2 and legacy release 3.0.6

[Wietse Venema]

Quanah Gibson-Mount:
> --On Monday, August 29, 2016 10:40 AM -0400 Wietse Venema 
>  wrote:
> 
> > [An on-line version of this announcement will be available at
> > http://www.postfix.org/announcements/postfix-3.1.2.html]
> 
> Are there any plans to add the 20160730-postscreen patch to future 2.11.x 
> and 3.x releases?

No. The patch is way too large for a stable release. If you care
about interoperability, don't turn on the after-220 checks. For the
same reasons as greylisting, the after-220 checks can result in
huge email delays

Wietse

Re: transport table ignored

[Noel Jones]

On 8/29/2016 12:17 PM, Jared Brokaw wrote:
> 
> 
> > I don't want any recipient address checking or validation or
> 
> In that case you should not be using Postfix.
> 
> 
> I meant I do not necessarily need/want recipient validation on the
> relay, just on the final destination for the time being. I don't
> want to have define every single user that will be receiving email
> on both the relay and on the final destination. It is only temporary
> after all.
> 

Postfix is not a proxy; messages are fully received, placed in the
postfix outgoing queue, and then sent to their destination.

If you blindly accept all recipients, your server will be filled
with dead mail -- mail for which no valid recipient exists, and
which cannot be returned to sender because the sender information is
invalid.  This will bring performance to a crawl.  Or worse, you'll
return mail to the wrong sender and be blacklisted as a backscatter
source.

In some cases, postfix may be able to automatically build a list of
valid recipients.  This isn't a perfect solution, but it's far
better than nothing.  For this to work, the downstream server must
correctly reject unknown recipients.
http://www.postfix.org/ADDRESS_VERIFICATION_README.html

Postfix must know valid recipients at the gateway, or you really
shouldn't be running a mail server.



  -- Noel Jones

Re: Trouble relaying email from Dovecot through postfix to another mail server after putting in client restrictions

[Noel Jones]

On 8/29/2016 11:34 AM, Scott W. Sander wrote:
> Here is the exact error message that is received by the mail client:

We prefer postfix log messages rather than messages from a mail
client that may have been altered.

> 
> ---
> 
> Server error: '554 5.7.1  [10.10.10.47]:51423>: Client host
> rejected: Access denied'
> 
> ---
> 
> I know that this error is caused by the smptd_client_restrictions
> parameter and not smptd_relay_restrictions.  Is there a way I can
> whitelist clients that authenticated to dovecot via IMAP in postfix
> as well as other application servers that are currently whitelisted
> by IP address?  I thought the permit_sasl_authenticated entry in
> smtpd_client_restrictions would have solved the issue, but it
> doesn't seem to.


The config line in questions:
> smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, 
> reject 

The client must either be listed in mynetworks, or must SASL AUTH to
postfix.  It does not consult dovecot to see who might be logged in
via IMAP.

The easy solution is to require your clients to use SASL when
sending mail.  If that isn't possible, then your restriction is too
strict.  Maybe you can use a check_client_access map with listed
exceptions rather than a flat reject.



  -- Noel Jones







> 
> Here is postconf -n:
> 
> ---
> 
> user@appserver4:~$ postconf -n
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> debug_peer_level = 1
> debug_peer_list = domain.com 
> inet_interfaces = all
> inet_protocols = all
> lmtp_tls_security_level = none
> mailbox_size_limit = 0
> mydestination = appserver4.subdomain.domain.com
> , localhost.domain.com
> , localhost, mail.domain.test
> myhostname = mail.domain.test
> mynetworks = 127.0.0.0/8  [:::127.0.0.0]/104
> [::1]/128 10.253.254.225 10.254.254.225 10.254.254.226
> 10.254.254.171 10.254.254.172
> myorigin = /etc/mailname
> readme_directory = no
> recipient_delimiter = +
> relay_domains = domain.com 
> relayhost = [exchangefe01.subdomain.domain.com
> ]
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_sasl_security_options = noanonymous
> smtp_sasl_type = cyrus
> smtp_tls_ciphers = medium
> smtp_tls_exclude_ciphers = aNULL, MD5, DES, ADH, RC4
> smtp_tls_mandatory_ciphers = medium
> smtp_tls_mandatory_exclude_ciphers = aNULL, MD5, DES, ADH, RC4
> smtp_tls_note_starttls_offer = yes
> smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1
> smtp_tls_security_level = encrypt
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
> smtpd_client_connection_rate_limit = 1000
> smtpd_client_message_rate_limit = 1000
> smtpd_client_new_tls_session_rate_limit = 1000
> smtpd_client_port_logging = yes
> smtpd_client_recipient_rate_limit = 3000
> smtpd_client_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname
> smtpd_recipient_limit = 3000
> smtpd_reject_unlisted_sender = no
> smtpd_relay_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_unverified_recipient,
> reject_unauth_destination
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_path = private/auth
> smtpd_sasl_type = dovecot
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/ssl/certs/apps4_combined.pem
> smtpd_tls_ciphers = medium
> smtpd_tls_exclude_ciphers = aNULL, MD5, DES, ADH, RC4
> smtpd_tls_key_file = /etc/ssl/private/apps4_key.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = medium
> smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5, DES, ADH, RC4
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_received_header = yes
> smtpd_tls_req_ccert = no
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_use_tls = yes
> strict_rfc821_envelopes = yes
> virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
> virtual_transport = lmtp:unix:private/dovecot-lmtp

Re: transport table ignored

[Jared Brokaw]

On Mon, Aug 29, 2016 at 4:53 PM, Noel Jones  wrote:

> On 8/29/2016 12:17 PM, Jared Brokaw wrote:
> >
> >
> > > I don't want any recipient address checking or validation or
> >
> > In that case you should not be using Postfix.
> >
> >
> > I meant I do not necessarily need/want recipient validation on the
> > relay, just on the final destination for the time being. I don't
> > want to have define every single user that will be receiving email
> > on both the relay and on the final destination. It is only temporary
> > after all.
> >
>
> Postfix is not a proxy; messages are fully received, placed in the
> postfix outgoing queue, and then sent to their destination.
>

It is now, at least for me anyway :) (joking) You folks are so serious...


>
> If you blindly accept all recipients, your server will be filled
> with dead mail -- mail for which no valid recipient exists, and
> which cannot be returned to sender because the sender information is
> invalid.  This will bring performance to a crawl.  Or worse, you'll
> return mail to the wrong sender and be blacklisted as a backscatter
> source.
>

I'm aware of the consequences. I know the server, the domains, the users,
mail and spam volume, etc... well enough to know that will not be a
problem. Under the circumstances where it will only be doing that for a
very limited period of time during DNS propagation delays, it's a perfectly
acceptable use case...again, at least to me it is.


> In some cases, postfix may be able to automatically build a list of
> valid recipients.  This isn't a perfect solution, but it's far
> better than nothing.  For this to work, the downstream server must
> correctly reject unknown recipients.
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
>
> Postfix must know valid recipients at the gateway, or you really
> shouldn't be running a mail server.
>

I once knew all those docs by heart. I believe I posted my configuration
indicating that I'm already doing all of that and have been for years.
There are also extenuating circumstances. I'm just moving a few low volume
domains, Lighten up!