using header_checks for custom transport

2012-03-16 Thread Pim Zandbergen
I am routing all mail for a domain to another SMTP server using the 
transport map rule


adomain.comrelay:other.server

But I would like to exclude mailing lists, and have them processed locally,
using header_checks entries like this:

/^X-Mailing-List:/FILTER local:

Here, local is the transport name, and the destination is empty as 
suggested in the
comments of the header_checks file. But that doesn't work, no filtering 
takes place,

the mail ends up being relaid.

/^X-Mailing-List:/REDIRECT some@address

does work, but I would prefer not to change the address.

Obviously there is a misunderstanding on my part regarding the FILTER syntax
Can I use a FILTER action to do what I want? I'm using Postfix 2.7.5

Thanks,
Pim


Re: using header_checks for custom transport

2012-03-16 Thread Viktor Dukhovni
On Fri, Mar 16, 2012 at 12:37:21PM +0100, Pim Zandbergen wrote:

 I am routing all mail for a domain to another SMTP server using the
 transport map rule
 
 adomain.comrelay:other.server

Good.

 But I would like to exclude mailing lists, and have them processed locally,
 using header_checks entries like this:
 
 /^X-Mailing-List:/FILTER local:

An MTA MUST NEVER route mail based on header content, headers only
imply recipients in the MUA in which the message is composed, or
in MUAs that delegate header parsing to the local submission
sendmail -t command.

Once a message has entered the mail stream, its recipients are
determined solely from the message envelope. This is CRITICAL,
otherwise messages to this list (for example) would loop, as the
headers would indicate the the message is addressed to the list,
rather than the envelope recipient, ...

 /^X-Mailing-List:/REDIRECT some@address

DO NOT do this. If a particular recipient wants his list traffic left
a local mailbox, and the rest forwarded, that's up the to user's
LDA, say procmail(1), or similar. This must not be done at the
message level by the MTA which processes mail for multiple
recipients.

--
Viktor.


Re: using header_checks for custom transport

2012-03-16 Thread Pim Zandbergen

On 16-3-2012 14:18, Viktor Dukhovni wrote:

/^X-Mailing-List:/REDIRECT some@address

DO NOT do this. If a particular recipient wants his list traffic left
a local mailbox, and the rest forwarded, that's up the to user's
LDA, say procmail(1), or similar. This must not be done at the
message level by the MTA which processes mail for multiple
recipients.


I agree, the other SMTP server that receives all the other mail, a popular
commercial groupware product, should handle the mailing list mail as well.
But it does so in an unsatisfying way.

So I need to intercept this mail before it gets handed over to this other
server. Here, local processing means submitting to Cyrus IMAP, and further
filtering by Cyrus' sieve which works much more satisfying than the other
servers' filtering mechanisms.

Pim


Re: using header_checks for custom transport

2012-03-16 Thread mouss
Le 16/03/2012 15:06, Pim Zandbergen a écrit :
 On 16-3-2012 14:18, Viktor Dukhovni wrote:
 /^X-Mailing-List:/REDIRECT some@address
 DO NOT do this. If a particular recipient wants his list traffic left
 a local mailbox, and the rest forwarded, that's up the to user's
 LDA, say procmail(1), or similar. This must not be done at the
 message level by the MTA which processes mail for multiple
 recipients.
 
 I agree, the other SMTP server that receives all the other mail, a popular
 commercial groupware product, should handle the mailing list mail as well.
 But it does so in an unsatisfying way.
 
 So I need to intercept this mail before it gets handed over to this other
 server. Here, local processing means submitting to Cyrus IMAP, and further
 filtering by Cyrus' sieve which works much more satisfying than the other
 servers' filtering mechanisms.
 


As Viktor said, don't route mail based on headers. use the recipient
address. your ML has a recipient address, no?
simply use virtual_alias_maps:

joel...@example.org joelist+example.org@localhost

of course, you can also use a transport entry:

joel...@example.org local: