Re: How to route mail to different isp-smarthosts depending on reply-to address

[Klaus Dittrich]

Am 02/19/17 um 18:25 schrieb Wietse Venema:

Robert Schetterer:

Am 19.02.2017 um 17:18 schrieb Klaus Dittrich:

What I want to achive is

an identity(me) with reply-to  kladit@isp-a should get routed to the
smart-host of isp-a

the same identity(me) with reply-to  kladit@isp-b should get routed to
the smart-host of isp-b

hm perhaps try with header checks on reply-to headers action transport
but i think that can result in unwanted routings cause in standard every
mail will pass header checks...wait for list better ideas

Perhaps you can configure Thunderbird to give your different
identities a different SENDER address. On the Postfix side, you can
then use the sender_dependent_relayhost_maps feature to pick the
smarthost.

Wietse


Wietse,

in Germany we have an old saw "someone could not see the the forrest because of too 
much trees".

The same happend to me.

I configured postfix accordingly to your suggestion and now I am a happy with
multiple identities without having lost my own :-)

Thank you very much for showing off the forrest to me.

--
Klaus

Re: postfix access map

[Dominic Raferd]

On 20 February 2017 at 07:58, Admin Beckspaced  wrote:

> Dear Postfix users,
>
> First a belated BIG THANK YOU to Wietse and his 20 years of Postfix.
> You're awesome!
>
> Second:
>
> I'm running Postfix version 2.11.6 and have setup an access map of sender
> email addresses
>
> someu...@somedomain.com OK
>
> then doing a postmap on the access map and in the main.cf I setup the
> following:
>
> smtpd_sender_restrictions =
> ​​
> hash:/etc/postfix/access
>
> and later in the main.cf I setup some recipient restrictions with checks
> on RBL
>
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated,
> ...
> reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org,
> ...
> permit
>
> Now I thought whenever I got an email from a sender listed in the access
> map it will always get delivered, because of the OK action, and will skip
> checks in the smtpd_recipient_restrictions?
>
> but today a customer send me the following:
>
> From: Mail Delivery System
> Sent: Sunday, February 19, 2017 10:22 AM
> To: someu...@somedomain.com
> Subject: Undelivered Mail Returned to Sender
>
> This is the mail system at host mailout04.t-online.de.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
>   The mail system
>
> : host mail.beckspaced.com[78.46.161.3] said: 554
> 5.7.1
>Service unavailable; Client host [194.25.134.18] blocked using
>bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtm
> l?194.25.134.18
>(in reply to RCPT TO command)
>
> and the sender was the email address listed in the access map.
>
> So I thought that email in the access map will never make it to the RBL
> checks and always will pass as OK?
>
> Is there anything I need to think of to make it work? Whitelist an email
> address to always get accepted?
>

An 'OK' in your access file only causes emails which match it to skip
further tests that occur in the one restriction list in which you have
mentioned it i.e. sender_restrictions. It doesn't affect the separate
restriction list 'recipient_restrictions' in which you have your RBLs (or
any other restriction lists). The solution is to duplicate or move
hash:/etc/postfix/access to being inside recipient_restrictions but above
your RBL checks.

Re: postfix access map

[Admin Beckspaced]

On 20.02.2017 09:35, Dominic Raferd wrote:



On 20 February 2017 at 07:58, Admin Beckspaced > wrote:


Dear Postfix users,

First a belated BIG THANK YOU to Wietse and his 20 years of
Postfix. You're awesome!

Second:

I'm running Postfix version 2.11.6 and have setup an access map of
sender email addresses

someu...@somedomain.com  OK

then doing a postmap on the access map and in the main.cf
 I setup the following:

smtpd_sender_restrictions =
​​
hash:/etc/postfix/access

and later in the main.cf  I setup some recipient
restrictions with checks on RBL

smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
...
reject_rbl_client bl.spamcop.net ,
reject_rbl_client zen.spamhaus.org ,
...
permit

Now I thought whenever I got an email from a sender listed in the
access map it will always get delivered, because of the OK action,
and will skip checks in the smtpd_recipient_restrictions?

but today a customer send me the following:

From: Mail Delivery System
Sent: Sunday, February 19, 2017 10:22 AM
To: someu...@somedomain.com 
Subject: Undelivered Mail Returned to Sender

This is the mail system at host mailout04.t-online.de
.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

  The mail system

mailto:i...@traenen123.com>>: host
mail.beckspaced.com [78.46.161.3]
said: 554 5.7.1
   Service unavailable; Client host [194.25.134.18] blocked using
bl.spamcop.net ; Blocked - see
http://www.spamcop.net/bl.shtml?194.25.134.18

   (in reply to RCPT TO command)

and the sender was the email address listed in the access map.

So I thought that email in the access map will never make it to
the RBL checks and always will pass as OK?

Is there anything I need to think of to make it work? Whitelist an
email address to always get accepted?


An 'OK' in your access file only causes emails which match it to skip 
further tests that occur in the one restriction list in which you have 
mentioned it i.e. sender_restrictions. It doesn't affect the separate 
restriction list 'recipient_restrictions' in which you have your RBLs 
(or any other restriction lists). The solution is to duplicate or move 
hash:/etc/postfix/access to being inside recipient_restrictions but 
above your RBL checks.


Thanks,

I always had the impression that an OK will skip all further tests in 
any restrictions lists following.


I now added in smtpd_recipient_restrictions before the RBL checks

check_sender_access hash:/etc/postfix/access

which will do what I want.

Is there perhaps any action which let's me pass all following 
restriction lists?


Thanks & greetings
Becki

Know wich mail client connect in postix

[Luis Miguel Flores dos Santos]

Hi, exist a way to know wich mail client try or are connected in 587? Like 
Android Mail, Outlook, thunderbird?


Thanks

Re: Know wich mail client connect in postix

[Geert Stappers]

On Mon, Feb 20, 2017 at 02:48:15PM +, Luis Miguel Flores dos Santos wrote:
> Hi, exist a way to know which mail client try or are connected in 587?
> Like Android Mail, Outlook, thunderbird?

No, because to protocol doesn't care about "which client".


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: postfix access map

[Viktor Dukhovni]

> On Feb 20, 2017, at 4:31 AM, Admin Beckspaced  wrote:
> 
> I always had the impression that an OK will skip all further tests in any 
> restrictions lists following.
> 
> I now added in smtpd_recipient_restrictions before the RBL checks
> 
> check_sender_access hash:/etc/postfix/access

Make sure this (and restrictions that it whitelists) occurs *AFTER*
"reject_unauth_destination", or else  that you're using
"reject_unauth_destination" in "smtpd_relay_restrictions" to prevent
open relay issues.

> Is there perhaps any action which let's me pass all following restriction 
> lists?

No.

-- 
Viktor.

Re: postfix access map

[Admin Beckspaced]

On 20.02.2017 17:54, Viktor Dukhovni wrote:

On Feb 20, 2017, at 4:31 AM, Admin Beckspaced  wrote:

I always had the impression that an OK will skip all further tests in any 
restrictions lists following.

I now added in smtpd_recipient_restrictions before the RBL checks

check_sender_access hash:/etc/postfix/access

Make sure this (and restrictions that it whitelists) occurs *AFTER*
"reject_unauth_destination", or else  that you're using
"reject_unauth_destination" in "smtpd_relay_restrictions" to prevent
open relay issues.


Is there perhaps any action which let's me pass all following restriction lists?

No.


Thanks ;) you guys on the mailing list are really doing a great job!

smtp-cache problem

[Thomas Minor]

Hello,

I might have a problem with the smtp_connection cache.
Regarding documentation, the cache is enabled on demand by default.

I found a peer site, which is also driven by postfix, with uses greylisting.
I have some 3000 mails to send to this particular server, which starts the 
session
by greylisting my server. Since postfix uses the smtp_connection_cache by 
default,
it reuses the connection which receives one greylisting temp fail after the 
other.
This seems to triggers the $smtpd_hard_error_limit on the other site. My server
continues to use now dead connection until the cache limits take effect.

I tend to assume, that this is a bug and maybe a configurable amount of errors 
should
trigger the sending postfix to abandon a connection.

Did i miss any configuration options here or do you agree?

Yours,

--Thomas


-- 

  Thomas Minor, Development

  H & R Netzwerk GmbH
  Am Königsweg 9
  48599 Gronau-Epe

  Sitz:Gronau / Westf.
  Handelsregister: Amtsgericht Coesfeld, HRB 5886
  Geschäftsführer: Harald Beine

--

Re: smtp-cache problem

[Wietse Venema]

Thomas Minor:
> Hello,
> 
> I might have a problem with the smtp_connection cache.
> Regarding documentation, the cache is enabled on demand by default.
> 
> I found a peer site, which is also driven by postfix, with uses greylisting.
> I have some 3000 mails to send to this particular server, which starts the 
> session
> by greylisting my server. Since postfix uses the smtp_connection_cache by 
> default,
> it reuses the connection which receives one greylisting temp fail after the 
> other.
> This seems to triggers the $smtpd_hard_error_limit on the other site. My 
> server
> continues to use now dead connection until the cache limits take effect.
> 
> I tend to assume, that this is a bug and maybe a configurable amount of 
> errors should
> trigger the sending postfix to abandon a connection.
> 
> Did i miss any configuration options here or do you agree?

Why should Postfix abandon a connection that replies with 4xx to a
recipient?  How is this different from sending a multi-recipient
message?

Wietse

Re: smtp-cache problem

[Viktor Dukhovni]

> On Feb 20, 2017, at 7:19 PM, Wietse Venema  wrote:
> 
> Why should Postfix abandon a connection that replies with 4xx to a
> recipient?  How is this different from sending a multi-recipient
> message?

I guess because hard error limits may induce tarpit controls on the
receiving side?

Mind you, a server doing greylisting should probably not employ tarpit
controls.  Another reason may be that once a remote "421" disconnect is
triggered by too many consecutive errors, we may (begin to) throttle the
destination.

As you point out, with greylisting, a multi-recipient message to O(100)
recipients may run into issues rather similar to the ones just reported
with connection re-use...

-- 
-- 
Viktor.