Re: transport_maps not taking on

2019-08-09 Thread Kai Schaetzl
Noel Jones wrote on Thu, 8 Aug 2019 10:49:54 -0500:

> That looks like a policy service and not a milter.

Yeah, right. It's a dovecot authenticator I think.

> 
> Regardless, postfix accepts mail, running it through all configured 
> milters, restrictions, and policy services, then puts it in the 
> queue.  THEN it consults the transport table to see where to deliver 
> it.  (this is somewhat over-simplification, but should answer your 
> question)

Yeah, thanks! The milter is getting consulted every time.
I think it works now.

And I've found out about the mysterious holds. It was an old header_check 
file on that machine. It wasn't used until I copied over the uncommented 
header_check directive.

Thanks!

Kai




Re: transport_maps not taking on

2019-08-08 Thread Noel Jones

On 8/8/2019 10:41 AM, Kai Schaetzl wrote:

I have still one question, though.

I fear that forwarding the mail via transport may not consult the milter.
At the moment the remote Exchange is still not configured to accept the
domain. I'm still waiting for that to take place.
In the meantime, though, I would have expected that the course of action
is the following:
- postfix accepts the mail to this domain
- applies the restrictions
- once the mail has successfully passed the restrictions
- it delivers to the transport-specified destination

But in this case I should see a connection to and validation by the milter
before postfix tells me that the remote Exchange won't accept it.
And it doesn't do that.
Or does it first check if it would be able to deliver to the destination
before it applies the other restrictions?

The rspamd milter is set to get consulted at the end of

smtpd_recipient_restrictions =
..
..
check_policy_service inet:127.0.0.1:10024,
permit

and: smtpd_delay_reject = yes

Will this check the milter before the message is sent over to the
transport-specified nexthop?

Thanks for a clarification!

Kai





That looks like a policy service and not a milter.

Regardless, postfix accepts mail, running it through all configured 
milters, restrictions, and policy services, then puts it in the 
queue.  THEN it consults the transport table to see where to deliver 
it.  (this is somewhat over-simplification, but should answer your 
question)



  -- Noel Jones


Re: transport_maps not taking on

2019-08-08 Thread Kai Schaetzl
I have still one question, though.

I fear that forwarding the mail via transport may not consult the milter.
At the moment the remote Exchange is still not configured to accept the 
domain. I'm still waiting for that to take place.
In the meantime, though, I would have expected that the course of action 
is the following:
- postfix accepts the mail to this domain
- applies the restrictions
- once the mail has successfully passed the restrictions
- it delivers to the transport-specified destination

But in this case I should see a connection to and validation by the milter 
before postfix tells me that the remote Exchange won't accept it.
And it doesn't do that.
Or does it first check if it would be able to deliver to the destination 
before it applies the other restrictions?

The rspamd milter is set to get consulted at the end of

smtpd_recipient_restrictions = 
..
..
check_policy_service inet:127.0.0.1:10024,
permit

and: smtpd_delay_reject = yes

Will this check the milter before the message is sent over to the 
transport-specified nexthop?

Thanks for a clarification!

Kai




Re: transport_maps not taking on

2019-08-08 Thread Kai Schaetzl
I went back to my original config with virtual users and domains, with and 
without the milter. I left transport and mynetworks as they were. I have 
no idea why, but it's working now and I get a bounce from the remote 
server (= it's not yet accepting the mail). No more attempts to deliver 
locally or put on hold. I hope it remains that way.
Thanks for the help!

Kai




Re: transport_maps not taking on

2019-08-08 Thread Kai Schaetzl
Wietse Venema wrote on Wed, 7 Aug 2019 19:33:05 -0400 (EDT):

> Once a message enters in the hold queue IT WILL SIT THERE FOREVER
> unless something releases it from that queue.

Understood. Thanks! I should have known from the past (see below).

> 
> You need to figure out why messages are placed on the hold queue.
> One example is when a Milter returns a "quarantine" action. Another
> one is Mailscanner.

I used to use MailScanner until one or two years ago. Yeah, you actually 
configure Postfix to put all incoming messages in the hold queue, 
MailScanner scans it and puts it actively in the delivery queue.

rspamd doesn't put them to quarantine. If I requeue the message with -r it 
is put on hold again very soon. According to man postsuper the requeue 
does not subject it to the milter again. But I will take it out of the 
equation for now to be sure. It looks to me like I must have disabled any 
attempt to deliver to a transport at all.

Kai




Re: transport_maps not taking on

2019-08-07 Thread Wietse Venema
Kai Schaetzl:
> Noel Jones wrote on Wed, 7 Aug 2019 13:37:08 -0500:
> 
> > Postfix logs all delivery attempts.
> 
> I thought so, but ...
> In that case it just hangs in the queue and nothing happens after the 
> milter was consulted. I can see it getting logged in rspamd and then it 
> just sits in the hold queue. Rescheduling it makes no difference. It 
> doesn't even log it.

Once a message enters in the hold queue IT WILL SIT THERE FOREVER
unless something releases it from that queue.

You need to figure out why messages are placed on the hold queue.
One example is when a Milter returns a "quarantine" action. Another
one is Mailscanner.

Wietse


Re: transport_maps not taking on

2019-08-07 Thread Kai Schaetzl
Noel Jones wrote on Wed, 7 Aug 2019 13:37:08 -0500:

> Postfix logs all delivery attempts.

I thought so, but ...
In that case it just hangs in the queue and nothing happens after the 
milter was consulted. I can see it getting logged in rspamd and then it 
just sits in the hold queue. Rescheduling it makes no difference. It 
doesn't even log it.

Kai




Re: transport_maps not taking on

2019-08-07 Thread Noel Jones

On 8/7/2019 1:11 PM, Kai Schaetzl wrote:

Kai Schaetzl wrote on Wed, 07 Aug 2019 19:11:19 +0200:


Should I remove the domain from $mydestination ?


I did that now and postfix still accepts the mail.
However, it doesn't deliver it to the remote server.
It hangs in the queue.

It's possible that the remote side is not accepting that (testing) domain
yet, but I can't verify this at the moment.
Shouldn't postfix at least show some logging that it can't deliver the
mail at the moment? I've set to -vv logging but still don't get anything
other than that mail was accepted. Flushing the queue doesn't give any
hint in the log either.



Postfix logs all delivery attempts.

Turn off the -vv debug logging; everything you need is in the normal 
logging.


If you need more help, please see:
http://www.postfix.org/DEBUG_README.html#mail



  -- Noel Jones


Re: transport_maps not taking on

2019-08-07 Thread Kai Schaetzl
Kai Schaetzl wrote on Wed, 07 Aug 2019 19:11:19 +0200:

> Should I remove the domain from $mydestination ?

I did that now and postfix still accepts the mail.
However, it doesn't deliver it to the remote server.
It hangs in the queue.

It's possible that the remote side is not accepting that (testing) domain 
yet, but I can't verify this at the moment.
Shouldn't postfix at least show some logging that it can't deliver the 
mail at the moment? I've set to -vv logging but still don't get anything 
other than that mail was accepted. Flushing the queue doesn't give any 
hint in the log either.



Kai




Re: transport_maps not taking on

2019-08-07 Thread Kai Schaetzl
Thanks for the reply, but no.
I had to, indeed, remove the domain from $mydestination to not deliver 
locally, but it's still not working correctly.

Your map configuration lines may be wrong.
I think the only thing you need is this as a destination:

/^List@List\.TLD$/mailman3:
(no [127.0.0.1]:8024 after it)
And your service runs as a socket, not on port 8024.

Kai




Re: transport_maps not taking on

2019-08-07 Thread Jay Gairson
Kai:

I think this issue might be the same as the one that I'm encountering in my
post yesterday titled, "Postfix not using LMTP Transport in map".

Can you look at your logs and see if you're getting a similar message to
what I have below?

Host postfix/lmtp[22981]: C0EEEA8: to=http://postfix.1071664.n5.nabble.com/user/SendEmail.jtp?type=node=102395=0>>,
orig_to=<[hidden email]
>,
relay=Host.TLD[private/dovecot-lmtp], delay=566, delays=566/0.04/0.01/0.01,
dsn=5.1.1, status=bounced (host Host.com[private/dovecot-lmtp] said: 550
5.1.1 <"mailman3:[127.0.0.1]:8024"@Host.TLD> User doesn't exist:
mailman3:[127.0.0.1]:[hidden email]

(in
reply to RCPT TO command))

Basically Postfix is reading the map, but applying it to the "To", but not
using the relay for it at all.  Instead it refers to the
private/dovecot-lmtp in my case as the relay.

Does this match the behavior you are seeing?





On Wed, Aug 7, 2019 at 10:11 AM Kai Schaetzl 
wrote:

> Postfix 3.1.0, set up with virtual domains and users in a database via
> virtual_ directives in main.cf
> rspamd set up as a milter
> -> everything works just fine.
>
> I have one server where the client wants to get mail delivered to his
> Exchange server remotely instead. He wants to have the mail floating
> through my postfix and use the spam marking by rspamd and then get it
> delivered to his Exchange.
>
> So I:
> - commented out all virtual_ lines
> - added the domain to $mydestination
> - added this to the transport map:
>   example.com   smtp:[IP]
>   (and compiled with postmap, of course, and)
>   (transport_maps = hash:/etc/mail/transport)
>
> Unfortunately, this doesn't work. It seems that the transport map is
> either not getting consulted or that line not getting used.
> The mail gets accepted but I get this error:
> Recipient address rejected: User unknown in local recipient table
> (or: if the user exists it gets delivered locally)
>
> I know I have done this in the past when I didn't use a virtual_ setup.
> What am I missing?
> Should I remove the domain from $mydestination ?
> What do I have to set additionally so that transport is getting consulted?
>
> Thanks a lot!
>
> Kai
>
>
>


transport_maps not taking on

2019-08-07 Thread Kai Schaetzl
Postfix 3.1.0, set up with virtual domains and users in a database via 
virtual_ directives in main.cf
rspamd set up as a milter
-> everything works just fine.

I have one server where the client wants to get mail delivered to his 
Exchange server remotely instead. He wants to have the mail floating 
through my postfix and use the spam marking by rspamd and then get it 
delivered to his Exchange.

So I:
- commented out all virtual_ lines
- added the domain to $mydestination
- added this to the transport map:
  example.com   smtp:[IP]
  (and compiled with postmap, of course, and)
  (transport_maps = hash:/etc/mail/transport)

Unfortunately, this doesn't work. It seems that the transport map is 
either not getting consulted or that line not getting used.
The mail gets accepted but I get this error:
Recipient address rejected: User unknown in local recipient table
(or: if the user exists it gets delivered locally)

I know I have done this in the past when I didn't use a virtual_ setup.
What am I missing?
Should I remove the domain from $mydestination ?
What do I have to set additionally so that transport is getting consulted?

Thanks a lot!

Kai