Re: header_checks in master.cf?

[/dev/rob0]

On Mon, Apr 04, 2011 at 06:33:20PM -0700, email builder wrote:
> I am testing a simple header_check that uses PREPEND to add a 
> custom header to messages.

Uh, no, I think it is not simple at all. Is this the same issue 
you're working on? You have spent much time, and gotten much help, 
none of which is actually getting you closer to the ultimate goal 
(whatever it may be, you really did not say.)

At some point you should ask: is it more difficult to keep on this 
path, or to buck the OS packaging system and *upgrade* to a recent 
Postfix version which probably CAN do what you want.

Since you mentioned 2.3.3 somewhere, I suppose that means RHEL or 
CentOS. Fortunately it is very easy to use a SRPM and rpmbuild(1). 
Simon Mudd maintains recent Postfix SRPMs. Go for 2.8.2 if he has 
posted that one already.

Disable any automated upgrades. Those have no place on any kind of 
server anyway. Why the fear of leaving the OS package?

> What am I missing?

As I mentioned last night in the other thread, OVERVIEW.html has 
Postfix's big picture, which might prevent you from wasting time 
working on things which are not possible. If you're going to stay 
with the ancient version, use its copy of the documentation, so as
to avoid the "This feature is available in Postfix 2.4 and later" 
gotchas.

As Jeroen mentioned in the second thread, you will do better here 
with complete problem and goal descriptions. All we know are the 
wacky, unworkable hacks you are trying to do. We don't know what 
you're really wanting to accomplish.

I suspect you need one of these three:
1. A more recent Postfix
2. A different MTA altogether
3. A more reasonable goal
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: header_checks in master.cf?

[email builder]

> > I am testing a simple  header_check that uses PREPEND to add a custom 
> > header 
>to 
>

> >  messages.
> > 
> > 1) I *always* want to add the header, so the detected  header in the rule 
>doesn't 
>
> > matter so much.  Does anyone have  advice for the best header to detect so 
> > I 

> > won't miss any  messages?  Is /^From:/ the best?  Or maybe /^Date:/ ?
> > 
> > Anyhow, my PREPEND is working fine as a header_check in main.cf, but when I 
>put 
>
> > it in master.cf in a smtpd listener  that picks up mail from my content 
>filter, 
>
> > it seems to be ignored  completely.  
> 
> According to header_checks(5) this is implemented by  the cleanup
> server.  header/body_checks are documented as parameters on  the
> cleanup(8) manpage.  They are not documented as parameters on  the
> smtpd(8) manpage.
> 
> All this confirms that header/body_checks are a  cleanup(8)
> feature, not an smtpd(8) feature, Meaning, it's pointless
> to  specify this on the smtpd(8) command line.

OK, sorry again.  I had assumed because you can turn off header checking by 
using receive_override_options, you could also override (change) them.

Reading smtpd(8) manpage, it does seem like smtpd_data_restrictions would be a 
good place to be able to inspect the mail headers and use the PREPEND to insert 
a new header.  But I was using check_client_access to do so, and that only 
seems 
to inspect the client address and related information  but looking through 
the list of restrictions I cannot understand which one allows the inspection of 
the message data itself.  

Re: header_checks in master.cf?

[Wietse Venema]

email builder:
> Hello,
> 
> I am testing a simple header_check that uses PREPEND to add a custom header 
> to 
> messages.
> 
> 1) I *always* want to add the header, so the detected header in the rule 
> doesn't 
> matter so much.  Does anyone have advice for the best header to detect so I 
> won't miss any messages?  Is /^From:/ the best?  Or maybe /^Date:/ ?
> 
> Anyhow, my PREPEND is working fine as a header_check in main.cf, but when I 
> put 
> it in master.cf in a smtpd listener that picks up mail from my content 
> filter, 
> it seems to be ignored completely.  

According to header_checks(5) this is implemented by the cleanup
server.  header/body_checks are documented as parameters on the
cleanup(8) manpage.  They are not documented as parameters on the
smtpd(8) manpage.

All this confirms that header/body_checks are a cleanup(8)
feature, not an smtpd(8) feature, Meaning, it's pointless
to specify this on the smtpd(8) command line.

Wietse

HEADER_CHECKS(5) HEADER_CHECKS(5)

NAME
   header_checks - Postfix built-in content inspection
...
DESCRIPTION
   This  document  describes access control on the content of
   message headers and message body lines; it is  implemented
   by  the  Postfix  cleanup(8) server before mail is queued.
   See access(5) for access control  on  remote  SMTP  client
   information.

Re: Multiple transport maps in master.cf?

[Wietse Venema]

email builder:
> > > > > Can I override  default_transport?
> 
> > >  > 
> > > > As  documented:
> > > > 
> > > >  http://www.postfix.org/postconf.5.html#default_transport
> > > 
> > > Right,  but from what I can tell (testing it), it's like transport_maps,
> > > in that  I can't change it willy-nilly in my smtpd process with a
> > > -o line,  right?  Works fine if specified in main.cf, but ignored
> > > if I set it in master.cf.
> > 
> > The parameter is  not documented in the smtpd(8) manpage, therefore
> > you are wasting your time  by setting it on the master.cf command
> > line.
> > 
> > I spend a huge amount of  time keeping the documentation complete,
> > and I would appreciate it if you  paid attention to the result of
> > this effort.
> > 
> > If you need per-sender  features, you must use a Postfix release
> > that supports  them.
> 
> Understood.  I hope you didn't infer that I was not thankful for
> the tremendous investment you must put into creating and maintaining
> such a wonderful tool.  I might be a little slow to understand it
> in detail (I am indeed reading documentation to the best of my
> ability), but don't mistake that for lack of gratitude on my part.

No offense taken. I was too harsh in my response.

Wietse

header_checks in master.cf?

[email builder]

Hello,

I am testing a simple header_check that uses PREPEND to add a custom header to 
messages.

1) I *always* want to add the header, so the detected header in the rule 
doesn't 
matter so much.  Does anyone have advice for the best header to detect so I 
won't miss any messages?  Is /^From:/ the best?  Or maybe /^Date:/ ?

Anyhow, my PREPEND is working fine as a header_check in main.cf, but when I put 
it in master.cf in a smtpd listener that picks up mail from my content filter, 
it seems to be ignored completely.  


I read that header_checks won't get certain headers such as From: in a smtpd 
process (um, I think?).  So I found a few examples that recommended to move it 
to smtpd_data_restrictions as a check_client_access table.  That didn't work 
either.  I also tried it as a smtpd_sender_restrictions check_sender_access 
table, but still no luck.

What am I missing?

127.0.0.1:10024 inet  n   -   n   -   -  smtpd
-o content_filter=
-o smtpd_delay_reject=no
-o 
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
# Doesn't work (yes, even when removing the line above):-o 
header_checks=pcre:/etc/posfix/add_header.pcre
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
# Doesn't work-o 
smtpd_sender_restrictions=check_sender_access,pcre:/etc/postfix/add_header.pcre
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
# Doesn't work-o 
smtpd_data_restrictions=reject_unauth_pipelining,check_client_access,pcre:/etc/postfix/add_header.pcre

-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o local_header_rewrite_clients=
-o mynetworks=127.0.0.0/8
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000

/etc/postfix/add_header.pcre is as follows

/^From: / PREPEND X-Custom-Header Hello_world

It works if I put this into main.cf:

header_checks = pcre:/etc/postfix/add_header.pcre

Thanks in advance

Re: Multiple transport maps in master.cf?

[email builder]

> > > > Can I override  default_transport?

> >  > 
> > > As  documented:
> > > 
> > >  http://www.postfix.org/postconf.5.html#default_transport
> > 
> > Right,  but from what I can tell (testing it), it's like transport_maps,
> > in that  I can't change it willy-nilly in my smtpd process with a
> > -o line,  right?  Works fine if specified in main.cf, but ignored
> > if I set it in master.cf.
> 
> The parameter is  not documented in the smtpd(8) manpage, therefore
> you are wasting your time  by setting it on the master.cf command
> line.
> 
> I spend a huge amount of  time keeping the documentation complete,
> and I would appreciate it if you  paid attention to the result of
> this effort.
> 
> If you need per-sender  features, you must use a Postfix release
> that supports  them.

Understood.  I hope you didn't infer that I was not thankful for the tremendous 
investment you must put into creating and maintaining such a wonderful tool.  I 
might be a little slow to understand it in detail (I am indeed reading 
documentation to the best of my ability), but don't mistake that for lack of 
gratitude on my part.

Re: Multiple transport maps in master.cf?

[Jeroen Geilman]

On 04/05/2011 12:09 AM, Victor Duchovni wrote:

On Mon, Apr 04, 2011 at 11:51:40PM +0200, Jeroen Geilman wrote:

   

The only Postfix service that consults the transport table is
trivial-rewrite(8), which in turn is consulted by smtpd(8), cleanup(8),
qmgr(8), ... with the main routing decision made in qmgr(8).

Postfix parameter settings don't get recorded in the queue file as
the message moves through the various stages of processing. Each
service (smtpd(8), cleanup(8), qmgr(8), smtp(8), ...) has its
own view of the configuration settings.
   

I thought some services could add extra info to queue messages, such as a
content_filter or smtpd proxy ?
 

These are not main.cf parameter overrides. The access(5) FILTER action
does not override the transport_maps setting in any other service. It
does record transport:nexthop *value* in the queue_file that pre-empts
normal transport lookups, but this is very different from changing some
other service's setting the variable that defines the list of tables to
consult.
   


Oh I missed that he wanted a completely different set of tables... 
sounds like multi-instance time, then.



The queue file containts the message envelope and body, plus a small
amount of metadata that includes DSN attributes, content encoding domain,
... and sometimes a content_filter setting. There are NO main.cf parameter
settings in the queue file.
   


Didn't mean to imply that there were, thanks for the clarification.



--
J.

Re: Multiple transport maps in master.cf?

[Victor Duchovni]

On Mon, Apr 04, 2011 at 11:51:40PM +0200, Jeroen Geilman wrote:

>> The only Postfix service that consults the transport table is
>> trivial-rewrite(8), which in turn is consulted by smtpd(8), cleanup(8),
>> qmgr(8), ... with the main routing decision made in qmgr(8).
>>
>> Postfix parameter settings don't get recorded in the queue file as
>> the message moves through the various stages of processing. Each
>> service (smtpd(8), cleanup(8), qmgr(8), smtp(8), ...) has its
>> own view of the configuration settings.
>
> I thought some services could add extra info to queue messages, such as a 
> content_filter or smtpd proxy ?

These are not main.cf parameter overrides. The access(5) FILTER action
does not override the transport_maps setting in any other service. It
does record transport:nexthop *value* in the queue_file that pre-empts
normal transport lookups, but this is very different from changing some
other service's setting the variable that defines the list of tables to
consult.

The queue file containts the message envelope and body, plus a small
amount of metadata that includes DSN attributes, content encoding domain,
... and sometimes a content_filter setting. There are NO main.cf parameter
settings in the queue file.

-- 
Viktor.

Re: Multiple transport maps in master.cf?

[Wietse Venema]

email builder:
> > > Can I override  default_transport?
> > 
> > As  documented:
> > 
> > http://www.postfix.org/postconf.5.html#default_transport
> 
> Right, but from what I can tell (testing it), it's like transport_maps,
> in that I can't change it willy-nilly in my smtpd process with a
> -o line, right?  Works fine if specified in main.cf, but ignored
> if I set it in master.cf.

The parameter is not documented in the smtpd(8) manpage, therefore
you are wasting your time by setting it on the master.cf command
line.

I spend a huge amount of time keeping the documentation complete,
and I would appreciate it if you paid attention to the result of
this effort.

If you need per-sender features, you must use a Postfix release
that supports them.

Wietse

Re: Multiple transport maps in master.cf?

[Jeroen Geilman]

On 04/04/2011 11:55 PM, email builder wrote:




- Original Message 
   

From: Wietse Venema
To: Postfix users
Sent: Mon, April 4, 2011 2:34:00 PM
Subject: Re: Multiple transport maps in master.cf?

email builder:
 

I've found that in main.cf, this works fine:
 

  >  >
 

  >   transport_maps =  hash:/etc/postfix/transport1
   

  >hash:/etc/postfix/transport2
   

  But not in master.cf (under a  smtpd  process  definition):

 

  >-o   transport_maps=hash:/etc/postfix/transport1
   

  >  >hash:/etc/postfix/transport2
   

smtpd  doesn't use  transport_maps
   

I realize that, but  I had read that it was "global", which  I thought
 

meant I

 

  could override it before a message was handed to  smtp.  I guess that  was
 
 

naive.
 

Can I override  default_transport?
   

As  documented:

http://www.postfix.org/postconf.5.html#default_transport
 

Right, but from what I can tell (testing it), it's like transport_maps, in that
I can't change it willy-nilly in my smtpd process with a -o line, right?  Works
fine if specified in main.cf, but ignored if I set it in master.cf.
   


I think you need to think hard about what it is you're trying to 
achieve, since the options postfix offers are quite flexible.


Try to re-state the problem, and see if it is solvable with the provided 
toolset.


It usually is.


--
J.

Re: Sending on different network interface

[Wietse Venema]

With Postfix < 2.7, you can't use FILTER to control the source IP
address while sending mail to a non-filter. That's why I had to
implement Feature 20100117.

If you want fancy features, upgrade, instead of asking to duplicate
the work. Postfix 2.3 is no longer maintained since early 2010.

Wietse

Re: Multiple transport maps in master.cf?

[email builder]

- Original Message 
> From: Wietse Venema 
> To: Postfix users 
> Sent: Mon, April 4, 2011 2:34:00 PM
> Subject: Re: Multiple transport maps in master.cf?
> 
> email builder:
> > > > > I've found that in main.cf, this works fine:
> > > 
> > >  > > 
> > > >  >  transport_maps =  hash:/etc/postfix/transport1  
> >  >hash:/etc/postfix/transport2
> > > > > 
> > > > >  But not in master.cf (under a  smtpd  process  definition):
> > > > > 
> > > >  >   -o   transport_maps=hash:/etc/postfix/transport1  
> >  > >hash:/etc/postfix/transport2
> > > > 
> > > > smtpd  doesn't use  transport_maps
> > > 
> > > I realize that, but  I had read that it was "global", which  I thought 
>meant I 
>
> > >  could override it before a message was handed to  smtp.  I guess that  
> > > was 
>
> > >naive.
> > 
> > Can I override  default_transport?
> 
> As  documented:
> 
> http://www.postfix.org/postconf.5.html#default_transport

Right, but from what I can tell (testing it), it's like transport_maps, in that 
I can't change it willy-nilly in my smtpd process with a -o line, right?  Works 
fine if specified in main.cf, but ignored if I set it in master.cf.

Re: Multiple transport maps in master.cf?

[Jeroen Geilman]

On 04/04/2011 11:26 PM, Victor Duchovni wrote:

On Mon, Apr 04, 2011 at 02:02:17PM -0700, email builder wrote:

   

Hello,

I've found that in main.cf, this works fine:

transport_maps = hash:/etc/postfix/transport1 hash:/etc/postfix/transport2

But not in master.cf (under a smtpd process definition):

   -o transport_maps=hash:/etc/postfix/transport1 hash:/etc/postfix/transport2
 

The only Postfix service that consults the transport table is
trivial-rewrite(8), which in turn is consulted by smtpd(8), cleanup(8),
qmgr(8), ... with the main routing decision made in qmgr(8).

Postfix parameter settings don't get recorded in the queue file as
the message moves through the various stages of processing. Each
service (smtpd(8), cleanup(8), qmgr(8), smtp(8), ...) has its
own view of the configuration settings.
   


I thought some services could add extra info to queue messages, such as 
a content_filter or smtpd proxy ?
This needs to include the last-previous hop it was supposed to go to 
before hitting either of the above, so it can continue there when it 
returns from external processing, i.e. no extra lookup for the transport 
route is done after returning from a content_filter - that was already 
set in cleanup.



--
J.

Re: Configuring multiple relays

[Jeroen Geilman]

On 04/04/2011 11:25 PM, deconya wrote:

Hi guys

Im looking how to make to config my postfix server to relay mails to 
other antispam server but filtering by domain. Actually Im using 
relayhost variable inside main.cf , but I need to 
mount different gateways for every domain. I understand with this 
main.cf  and using transport maps works fine?


My main.cf  (most important part):

myhostname = postfixserver
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mydomain.com , sub1.mydomain.com 
, sub2.mydomain.com 
 test.mydomain.com 
, localhost
mynetworks = 127.0.0.0/8  [:::127.0.0.0]/104 
[::1]/128 10.0.0.0/24  192.168.10.0/24 


mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

virtual_mailbox_base = /var/spool/dovecot/
virtual_create_mailbox_dirsize = yes
virtual_mailbox_extended = yes

virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf 
,ldap:/etc/postfix/ldap_aliases2.cf 

virtual_mailbox_maps = ldap:/etc/postfix/ldap_aliases.cf 
,ldap:/etc/postfix/ldap_aliases2.cf 

smtpd_sender_login_maps = ldap:/etc/postfix/ldap_aliases.cf 
,ldap:/etc/postfix/ldap_aliases2.cf 




mailbox_transport = dovecot
mailbox_command = /usr/lib/dovecot/deliver
dovecot_destination_concurrency_limit = 1
dovecot_destination_recipient_limit = 1
virtual_transport = dovecot

recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
transport_maps = hash:/etc/postfix/transport
mailman_destination_recipient_limit = 1
home_mailbox =

# MESSAGE SIZE #
message_size_limit = 2024

-

And transport

mydomain.comrelay:[10.0.0.10]
sub1.mydomain.comrelay:[10.0.0.10]
sub2.mydomain.comrelay:[10.0.0.10]
test.mydomain.comrelay:[10.0.0.11] 

I need to config more things? If I send a message to 
test@test.mydomain,com is necessary to config any in master.cf 
?


Did you TEST it ?
Does it WORK ?

To enable us to help you with configuration issues, include the output 
from postconf -n, not main.cf, and relevant logs that show what is not 
working as expected.


--
J.

Re: Sending on different network interface

[email builder]

> > OK, thank you very much for the pointer to  smtp_bind_address.  That's what 
> > I 
>

> > need, but I'm stumbling at the  transport map.  I already have outgoing 
> > mail 

> > segregated how I want  it when it exits my content filtering (ready to be 
>sent 
>
> > out).  So  ideally, the content filter (actually the specialized smtpd 
>process 
>
> >  that accepts mail from the content filter) could hand off to a specific 
> > smtp 
>
> > process that has the needed smtp_bind_address.  
> 
> The smtpd  process does not choose the smtp process. 

Fair enough.

> This quote from  RELEASE_NOTES-2.7 describes two solutions that may
> be of interest: see  Feature 20100117 and Feature 20091209 below.

Yes, especially feature 20100117.  Thank you very much for your work on those 
new features.

Unfortunately, I'm stuck with version 2.3.3 (bah! yum!), so I've been trying to 
find other ways to accomplish this.  I thought I might be able to override 
transport_maps (or default_transport?) in a smtpd process that gets mail back 
from the content filter, but I have been educated that this is not possible 
(see 
thread "Multiple transport maps in master.cf?").

Anyone have any other tricks up their sleeve that could address this (beside 
multiple instances)?  


It looks like if I can make the smtpd process add some kind of special header 
(is this possible?), then maybe I can do what was done here:

http://marc.info/?l=postfix-users&m=113351892721907&w=2

Is that work-able?

  - smtpd add a custom header
  - define a header check that detects the special header and filters those 
messages off to a special smtp process (and hopefully remove the special 
header, 
but OK if not)


> Feature 20091209 triggers  only on the envelope sender address,
> while Feature 20100117 can trigger on  any message property including
> a string in the header or body. 
> 
> Both  require that mail is split into classes, and all mail in class
> X is sent out  from an SMTP client IP address that is reserved for
> class X. For each class  you configure master.cf one  Postfix SMTP
> client for each SMTP source IP address, where each client has  its
> own "-o myhostname" and "-o smtp_bind_address"  settings.
> 
> /etc/postfix/master.cf:
> smtp1   unix  -   -   n-   -   smtp
>  -o smtp_bind_address=192.168.1.1 -o myhostname=hostname1
>  smtp2  unix  -   -n   -   -smtp
> -o smtp_bind_address=192.168.1.2 -o  myhostname=hostname2
> 
> With Feature 20100117 you'd specify actions of  "FILTER smtp1:" or
> "FILTER smtp2:" in an smtpd access(5) table,  header_checks(5) or
> body_checks(5). For example, in an access  table:
> 
> /etc/postfix/main.cf:
> smtpd_sender_restrictions  =
> check_sender_accesss  hash:/etc/postfix/sender_access
> 
> /etc/postfix/sender_access:
>  sender1FILTER smtp1:
>  sender2FILTER smtp2:
> 
> With Feature 20091209 you'd  have:
> 
> /etc/postfix/main.cf:
>  sender_dependent_default_transport_maps = 
>  hash:/etc/postfix/sender_transport
> 
> /etc/postfix/sender_transport:
>  sender1smtp1
>  sender2smtp2
> 
> Wietse
> 
> Major  changes - sender reputation
> -
> 
> [Feature  20100117] The FILTER action in access maps or header/body_checks
> now supports  sender reputation schemes that dynamically choose the
> SMTP source IP address.  Typically, mail is split into classes, and
> all mail in class X is sent out  from an SMTP client IP address that
> is reserved for class X.
> 
> This is  implemented by specifying FILTER actions with empty next-hop
> destinations in  access maps or header/body_checks, and by configuring
> in master.cf one  Postfix SMTP client for each SMTP source IP address,
> where each client has  its own "-o myhostname" and "-o smtp_bind_address"
> settings.
> 
> [Feature  20091209] sender_dependent_default_transport_maps, a
> per-sender override for  default_transport. The original motivation
> is to use different output  channels (with different source IP
> addresses) for different sender addresses,  in order to keep their
> IP-based reputations separate from each  other.
> 
> The result value syntax is that of default_transport, not  transport_maps.
> Thus, sender_dependent_default_transport_maps does not  support the
> special transport_maps result value syntax for null transport,  null
> nexthop, or null email address.
> 

Re: Multiple transport maps in master.cf?

[Wietse Venema]

email builder:
> > > > I've found that in main.cf, this works fine:
> > 
> > > > 
> > >  >  transport_maps = hash:/etc/postfix/transport1   
> >hash:/etc/postfix/transport2
> > > > 
> > > > But not in master.cf (under a smtpd  process  definition):
> > > > 
> > > >   -o   transport_maps=hash:/etc/postfix/transport1  
> > >hash:/etc/postfix/transport2
> > > 
> > > smtpd doesn't use  transport_maps
> > 
> > I realize that, but I had read that it was "global", which  I thought meant 
> > I 
> > could override it before a message was handed to  smtp.  I guess that was 
> >naive.
> 
> Can I override default_transport?

As documented:

http://www.postfix.org/postconf.5.html#default_transport

Wietse

Re: segfault when running postconf on Solaris

[Wietse Venema]

Wietse Venema:
> Rudy Gevaert:
> > Hello list,
> > 
> > I am getting a segfault when I run postconf on Solaris 10
> > SunOS horus 5.10 Generic_142910-17 i86pc i386 i86pc
> > 
> > postconf -n doesn't segfault!
> > 
> > running it with truss:
> > 
> > smtpd_discard_ehlo_keyword_address_maps =
> > smtpd_discard_ehlo_keywords =
> > smtpd_end_of_data_restrictions14374:write(1, " o w q\n s m t p _ a d 
> > d".., 4096)= 4096
> > 14374:  Incurred fault #6, FLTBOUNDS  %pc = 0x080775C4
> > 14374:siginfo: SIGSEGV SEGV_MAPERR addr=0x
> > 14374:  Received signal #11, SIGSEGV [default]
> > 14374:siginfo: SIGSEGV SEGV_MAPERR addr=0x
> > 
> > Any ideas what this could be?
> 
> Apparently, there is a problem with one of the parameters that is
> not in your main.cf file, and that has a name that comes after
> smtpd_end_of_data_restrictions. That leaves us with only 176
> possibilities.
> 
> To narrow the search down, use
> 
> $ gdb postconf
> (gdb) run
> ...crash...
> (gdb) where
> 
> > I'm running Ihsan's great postfix package! (http://ihsan.dogan.ch/postfix).

I installed Ihsan's postfix-2.8.2 package on my test virtual machine

SunOS solaris10 5.10 Generic i86pc i386 i86pc

with your main.cf, and I have no errors with postconf.

Wietse

Re: Multiple transport maps in master.cf?

[email builder]

- Original Message 
> From: email builder 
> To: postfix-users@postfix.org
> Sent: Mon, April 4, 2011 2:18:01 PM
> Subject: Re: Multiple transport maps in master.cf?
> 
> > > I've found that in main.cf, this works fine:
> 
> > > 
> >  >  transport_maps = hash:/etc/postfix/transport1   
>hash:/etc/postfix/transport2
> > > 
> > > But not in master.cf (under a smtpd  process  definition):
> > > 
> > >   -o   transport_maps=hash:/etc/postfix/transport1  
> >hash:/etc/postfix/transport2
> > 
> > smtpd doesn't use  transport_maps
> 
> I realize that, but I had read that it was "global", which  I thought meant I 
> could override it before a message was handed to  smtp.  I guess that was 
>naive.

Can I override default_transport?

Re: Multiple transport maps in master.cf?

[Victor Duchovni]

On Mon, Apr 04, 2011 at 02:02:17PM -0700, email builder wrote:

> Hello,
> 
> I've found that in main.cf, this works fine:
> 
> transport_maps = hash:/etc/postfix/transport1 hash:/etc/postfix/transport2
> 
> But not in master.cf (under a smtpd process definition):
> 
>   -o transport_maps=hash:/etc/postfix/transport1 hash:/etc/postfix/transport2

The only Postfix service that consults the transport table is
trivial-rewrite(8), which in turn is consulted by smtpd(8), cleanup(8),
qmgr(8), ... with the main routing decision made in qmgr(8).

Postfix parameter settings don't get recorded in the queue file as
the message moves through the various stages of processing. Each
service (smtpd(8), cleanup(8), qmgr(8), smtp(8), ...) has its
own view of the configuration settings.

-- 
Viktor.

Configuring multiple relays

[deconya]

Hi guys

Im looking how to make to config my postfix server to relay mails to other
antispam server but filtering by domain. Actually Im using relayhost
variable inside main.cf, but I need to mount different gateways for every
domain. I understand with this main.cf and using transport maps works fine?

My main.cf (most important part):

myhostname = postfixserver
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mydomain.com, sub1.mydomain.com ,
sub2.mydomain.com  test.mydomain.com, localhost
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 10.0.0.0/24
192.168.10.0/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

virtual_mailbox_base = /var/spool/dovecot/
virtual_create_mailbox_dirsize = yes
virtual_mailbox_extended = yes

virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf,ldap:/etc/postfix/
ldap_aliases2.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap_aliases.cf,ldap:/etc/postfix/
ldap_aliases2.cf
smtpd_sender_login_maps = ldap:/etc/postfix/ldap_aliases.cf
,ldap:/etc/postfix/ldap_aliases2.cf


mailbox_transport = dovecot
mailbox_command = /usr/lib/dovecot/deliver
dovecot_destination_concurrency_limit = 1
dovecot_destination_recipient_limit = 1
virtual_transport = dovecot

recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
transport_maps = hash:/etc/postfix/transport
mailman_destination_recipient_limit = 1
home_mailbox =

# MESSAGE SIZE #
message_size_limit = 2024

-

And transport

mydomain.comrelay:[10.0.0.10]
sub1.mydomain.comrelay:[10.0.0.10]
sub2.mydomain.comrelay:[10.0.0.10]
test.mydomain.comrelay:[10.0.0.11] 

I need to config more things? If I send a message to test@test.mydomain,com
is necessary to config any in master.cf?

Thanks and Best Regards

Re: Multiple transport maps in master.cf?

[email builder]

> > I've found that in main.cf, this works fine:

> > 
> >  transport_maps = hash:/etc/postfix/transport1  hash:/etc/postfix/transport2
> > 
> > But not in master.cf (under a smtpd process  definition):
> > 
> >   -o  transport_maps=hash:/etc/postfix/transport1  
>hash:/etc/postfix/transport2
> 
> smtpd doesn't use transport_maps

I realize that, but I had read that it was "global", which I thought meant I 
could override it before a message was handed to smtp.  I guess that was naive.

> >  I tried with comma-delimted instead of spaces, but no dice.  Is this a  
>syntax 
>
> > limitation in master.cf or a syntax misunderstanding on my  part?  Or?
> 
> You probably need multiple instances.

Been trying to figure out anything but.  But yeah...

Re: Multiple transport maps in master.cf?

[email builder]

> I've found that in main.cf, this works fine:

> 
> transport_maps =  hash:/etc/postfix/transport1 hash:/etc/postfix/transport2
> 
> But not in master.cf (under a smtpd process  definition):
> 
>   -o transport_maps=hash:/etc/postfix/transport1  hash:/etc/postfix/transport2
> 
> Postfix complains:
> 
> fatal:  unexpected command-line argument: hash:/etc/postfix/transport2
> 
> I tried  with comma-delimted instead of spaces, but no dice.  Is this a 
> syntax 

> limitation in master.cf or a syntax misunderstanding on my part?   Or?

Er, with more testing, it looks like I can't even override transport_maps in 
master.cf at all(?).

I have a run-of-the-mill transport map in main.cf, and in master.cf, I was 
hoping to override it when it gets back from content filtering:

127.0.0.1:10024 inet  n   -   n   -   -  smtpd
-o content_filter=
-o 
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o transport_maps=hash:/etc/postfix/transport2

So transport_maps is static, un-mutable?

Re: Multiple transport maps in master.cf?

[Ralf Hildebrandt]

* email builder :
> Hello,
> 
> I've found that in main.cf, this works fine:
> 
> transport_maps = hash:/etc/postfix/transport1 hash:/etc/postfix/transport2
> 
> But not in master.cf (under a smtpd process definition):
> 
>   -o transport_maps=hash:/etc/postfix/transport1 hash:/etc/postfix/transport2

smtpd doesn't use transport_maps

> I tried with comma-delimted instead of spaces, but no dice.  Is this a syntax 
> limitation in master.cf or a syntax misunderstanding on my part?  Or?

You probably need multiple instances.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: smtpd_sender_restrictions for alias?

[Jonas H.]

On 04/04/2011 04:29 PM, Noel Jones wrote:

The example is here:
http://www.postfix.org/RESTRICTION_CLASS_README.html#internal

You can use as many or as few addresses as required.


Thanks Noel, that's exactly what I searched for!

Multiple transport maps in master.cf?

[email builder]

Hello,

I've found that in main.cf, this works fine:

transport_maps = hash:/etc/postfix/transport1 hash:/etc/postfix/transport2

But not in master.cf (under a smtpd process definition):

  -o transport_maps=hash:/etc/postfix/transport1 hash:/etc/postfix/transport2


Postfix complains:

fatal: unexpected command-line argument: hash:/etc/postfix/transport2

I tried with comma-delimted instead of spaces, but no dice.  Is this a syntax 
limitation in master.cf or a syntax misunderstanding on my part?  Or?

Re: FW: Newbie question - being spammed using valid recipients

[Jeroen Geilman]

On 04/04/2011 06:49 PM, Bailey, Damian S. wrote:


Good afternoon!

Our school district has been using a Postfix/Amavis/SpamAssassin 
config for over a year now with good results.  Just recently, however, 
I've noticed that my mail filtering box has been hit by a spammer that 
uses a handful of email addresses to send mail to all legitimate 
senders in our domain.  This caused my filter to queue up mail into 
the 1700+ range, effectively delaying mail delivery.


We already reject mail going to undeliverable recipients by querying 
LDAP via a perl script.




Urk ? You do realize that postfix has built-in LDAP support, yes ?

Granted, all the mail in question was dumped as spam, but it still 
caused mail to be delayed.  Is there a way in Postfix that I can flag 
or alert if a certain sender is attempting to send more than X emails 
in a certain time?




You can block them from doing that; read this part of the TUNING README:

http://www.postfix.org/TUNING_README.html#conn_limit

At this point I am not allowed to turn on "check for legitimate 
senders" to block mail from falsified email addresses, for fear of 
lost legitimate email from poorly-configured mail servers and DNS records.


For instance, say we have 500 employees with email accounts.  If I 
have a single sender that sends to more than 200 of them, I would want 
to review it as a possible spamming attack.


Has anyone run into this?



How much of a problem $random_spam is heavily dependent on the 
preventative measures in place, and where you use them.


Proper DNS blacklisting and HELO checks go a long way to keeping your 
connections away from expensive spamassassin processes, and tying up 
legitimate SMTP connections.


If you're using postfix 2.8, look into postscreen(8) for a very 
effective way to cut down on the chatter from spammers.



--
J.

Re: segfault when running postconf on Solaris

[Wietse Venema]

Rudy Gevaert:
> Hello list,
> 
> I am getting a segfault when I run postconf on Solaris 10
> SunOS horus 5.10 Generic_142910-17 i86pc i386 i86pc
> 
> postconf -n doesn't segfault!
> 
> running it with truss:
> 
> smtpd_discard_ehlo_keyword_address_maps =
> smtpd_discard_ehlo_keywords =
> smtpd_end_of_data_restrictions14374:write(1, " o w q\n s m t p _ a d 
> d".., 4096)= 4096
> 14374:  Incurred fault #6, FLTBOUNDS  %pc = 0x080775C4
> 14374:siginfo: SIGSEGV SEGV_MAPERR addr=0x
> 14374:  Received signal #11, SIGSEGV [default]
> 14374:siginfo: SIGSEGV SEGV_MAPERR addr=0x
> 
> Any ideas what this could be?

Apparently, there is a problem with one of the parameters that is
not in your main.cf file, and that has a name that comes after
smtpd_end_of_data_restrictions. That leaves us with only 176
possibilities.

To narrow the search down, use

$ gdb postconf
(gdb) run
...crash...
(gdb) where

> I'm running Ihsan's great postfix package! (http://ihsan.dogan.ch/postfix).

Which version?

Wietse

Re: FW: Newbie question - being spammed using valid recipients

[Victor Duchovni]

On Mon, Apr 04, 2011 at 12:49:07PM -0400, Bailey, Damian S. wrote:

> Our school district has been using a Postfix/Amavis/SpamAssassin config
> for over a year now with good results.  Just recently, however, I've
> noticed that my mail filtering box has been hit by a spammer that uses a
> handful of email addresses to send mail to all legitimate senders in our
> domain.  This caused my filter to queue up mail into the 1700+ range,
> effectively delaying mail delivery.

Perhaps you can re-tune the filter to reduce per-message latency, remote
DNS lookups in the filter, ... have a high cost under load.

> We already reject mail going to undeliverable recipients by querying
> LDAP via a perl script.

Can you elaborate on this? Do you mean that you build snapshot tables
from LDAP and use these to reject invalid recipients before mail is
queued?

> Granted, all the mail in question was dumped as spam, but it still
> caused mail to be delayed.  Is there a way in Postfix that I can flag or
> alert if a certain sender is attempting to send more than X emails in a
> certain time?

A policy service should be able to do this. Look on the add-ons page:

http://www.postfix.org/addon.html#policy

This is most appropriate for authenticated submission users, but more
risky for the main SMTP port, as there may well be legitimate reasons
for a single sender to send mail to large number of users.

> For instance, say we have 500 employees with email accounts.  If I have
> a single sender that sends to more than 200 of them, I would want to
> review it as a possible spamming attack.

If you only want to protect your filter capacity, you can count messages
instead of recipients, and return 421 when a sender reaches a message
rate limit. Alternatively, the policy service can put all mail from
that sender in the "hold" queue, but then you need a process whereby
such mail is reviewed and either released, or deleted.

In general, I don't recommend rate limits, they unnecessarily penalize
legitimate senders of email. It is better to improve spam filtering
with well chosen RBLs, postscreen, ...

-- 
Viktor.

Re: segfault when running postconf on Solaris

[Victor Duchovni]

On Mon, Apr 04, 2011 at 06:28:20PM +0200, Rudy Gevaert wrote:

> Hello list,
>
> I am getting a segfault when I run postconf on Solaris 10
> SunOS horus 5.10 Generic_142910-17 i86pc i386 i86pc
>
> postconf -n doesn't segfault!
>
>
> running it with truss:
>
> smtpd_discard_ehlo_keyword_address_maps =
> smtpd_discard_ehlo_keywords =
> smtpd_end_of_data_restrictions14374:write(1, " o w q\n s m t p _ a d 
> d".., 4096)= 4096
> 14374:  Incurred fault #6, FLTBOUNDS  %pc = 0x080775C4
> 14374:siginfo: SIGSEGV SEGV_MAPERR addr=0x
> 14374:  Received signal #11, SIGSEGV [default]
> 14374:siginfo: SIGSEGV SEGV_MAPERR addr=0x
>
> Any ideas what this could be?

Report a backtrace from "gdb", not "truss" output. Which release
of Postfix is this? You should be using 2.8.2.

-- 
Viktor.

FW: Newbie question - being spammed using valid recipients

[Bailey, Damian S.]

Good afternoon!

 

Our school district has been using a Postfix/Amavis/SpamAssassin config
for over a year now with good results.  Just recently, however, I've
noticed that my mail filtering box has been hit by a spammer that uses a
handful of email addresses to send mail to all legitimate senders in our
domain.  This caused my filter to queue up mail into the 1700+ range,
effectively delaying mail delivery.

 

We already reject mail going to undeliverable recipients by querying
LDAP via a perl script.

 

Granted, all the mail in question was dumped as spam, but it still
caused mail to be delayed.  Is there a way in Postfix that I can flag or
alert if a certain sender is attempting to send more than X emails in a
certain time?

 

At this point I am not allowed to turn on "check for legitimate senders"
to block mail from falsified email addresses, for fear of lost
legitimate email from poorly-configured mail servers and DNS records.

 

For instance, say we have 500 employees with email accounts.  If I have
a single sender that sends to more than 200 of them, I would want to
review it as a possible spamming attack.

 

Has anyone run into this?  

 

Thanks.

 

Damian Bailey | baile...@lcps.k12.va.us

Lead Technician | LCPS Technology

540.894.4373x8220

Shipping Address:

Louisa County Public Schools

953 Davis Hwy

Mineral VA 23117

 

segfault when running postconf on Solaris

[Rudy Gevaert]

Hello list,

I am getting a segfault when I run postconf on Solaris 10
SunOS horus 5.10 Generic_142910-17 i86pc i386 i86pc

postconf -n doesn't segfault!


running it with truss:

smtpd_discard_ehlo_keyword_address_maps =
smtpd_discard_ehlo_keywords =
smtpd_end_of_data_restrictions14374:write(1, " o w q\n s m t p _ a d 
d".., 4096)= 4096

14374:  Incurred fault #6, FLTBOUNDS  %pc = 0x080775C4
14374:siginfo: SIGSEGV SEGV_MAPERR addr=0x
14374:  Received signal #11, SIGSEGV [default]
14374:siginfo: SIGSEGV SEGV_MAPERR addr=0x

Any ideas what this could be?


I'm running Ihsan's great postfix package! (http://ihsan.dogan.ch/postfix).


I have attached my main.cf and master.cf

Thanks!!

Rudy

# THIS FILE IS MANAGED WITH PUPPET DO NOT EDIT

smtpd_banner = $myhostname ESMTP $mail_name
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

mydomain = UGent.be
alias_maps = dbm:/etc/aliases
alias_database = dbm:/etc/aliases
mydestination= $myhostname
relayhost = smtprelay.ugent.be
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
message_size_limit = 12288000

config_directory = /etc/postfix
debug_peer_level = 2
mail_owner = postfix
setgid_group = postdrop
unknown_local_recipient_reject_code = 550

# THIS FILE IS MANAGED WITH PUPPET DO NOT EDIT

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==
# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (yes)   (never) (100)
# ==
smtp  inet  n   -   n   -   -   smtpd
#submission inet n   -   n   -   -   smtpd
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#smtps inet  n   -   n   -   -   smtpd
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628   inet  n   -   n   -   -   qmqpd
pickupfifo  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
#qmgr fifo  n   -   n   300 1   oqmgr
tlsmgrunix  -   -   n   1000?   1   tlsmgr
rewrite   unix  -   -   n   -   -   trivial-rewrite
bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce
verifyunix  -   -   n   -   1   verify
flush unix  n   -   n   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
smtp  unix  -   -   n   -   -   smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix  -   -   n   -   -   smtp
-o smtp_fallback_relay=
#   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
retry unix  -   -   n   -   -   error
discard   unix  -   -   n   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   n   -   -   lmtp
anvil unix  -   -   n   -   1   anvil
scacheunix  -   -   n   -   1   scache
#
# 
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# 
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
#maildrop  unix  -   n   n   -   -   pipe
#  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipi

Re: smtpd_sender_restrictions for alias?

[Noel Jones]

On 4/4/2011 4:26 AM, Jonas H. wrote:

I'm using Postfix aliases for a small mailing list. I'd like
to make sure only a few e-mail addresses can post, so I found
this smtpd_sender_restrictions thing. However, I couldn't find
out if one can use that for a single alias? If not, is there
any other way to accomplish this?

Thanks,
Jonas


The example is here:
http://www.postfix.org/RESTRICTION_CLASS_README.html#internal

You can use as many or as few addresses as required.


  -- Noel Jones

Re: sender and recipient check on submit server

[Noel Jones]

On 4/4/2011 3:35 AM, Gábor Lénárt wrote:

Hi,

I have a mail submit server for our users. What I would like is checking
sender and rcpt addresses if they belong to the domains at least which are
handled by us (of course I can't check if mail is sent to another domain
where I don't know the valid addresses, and I don't want to do SAV).

I have valid addresses and our domain list in LDAP. What made me thing that
it's possible at all to do this without a custom policy server:

1. check if domain part of the address is listed as our domain in LDAP
if not, there is no further check by address validation (well, just the
usual DNS ones)
2. if mailing of domain is handled by us, check if there is an address
like "localpart@domain" or "@domain" (the second form is used to signal
that all localparts are valid within that domain, ie: user has own MTA
or so). If there is no match, I want to reject the mail submission.
3. Of course I want my users to use SMTP authentication (it works,
using dovecot auth, just I mention here). Also some users may allowed
to send mails without SMTP authentication from some well defined IP
addresses though (also stored in LDAP).

I used the notion of "address" because I would like to have the same check
for rcpt and sender, because it also does not make too much sense to use
an invalid sender (not existing within the domain handled by us). Point 3 is
only an additional information, the important part is 1+2.

Of course I can do basic ldap lookups with postfix, but I am not sure it's
possible at all, to have more complex conditions, I mean: loc@domain can
be valid or invalid based on the fact that "domain" is handled by us or not.
So basically I need at least two queries it seems: if we handle a given
domain then: if it is, is the "loc" local part is valid or not.

Additional information: I would like to do this with only ldap maps at smtpd
sender and recipient restrictions (not with postfix's rcpt/sender maps etc),
since I want my own messages (including Hungarian) not postfix's built-in
ones.  Is it possble, or should I write a policy server instead? Or am I
wrong somewhere in my theory about solving this problem? (on long term I
have the idea to use _only_ policy server to decide, since I can use SQL
based logging from the policy server at every protocol state, I can do
custom complicated queries and conditions, also I can use my own messages
everywhere, etc. But for now there would be cool to have some more quick
solution for the problem I've described).

Thanks a lot in advance,

Gábor



If you have your recipient maps configured correctly, you can 
use the built-in controls.


http://www.postfix.org/postconf.5.html#reject_unlisted_recipient
http://www.postfix.org/postconf.5.html#reject_unlisted_recipient

http://www.postfix.org/postconf.5.html#reject_unlisted_sender
http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_sender



  -- Noel Jones

Re: Sending on different network interface

[Wietse Venema]

email builder:
> OK, thank you very much for the pointer to smtp_bind_address.  That's what I 
> need, but I'm stumbling at the transport map.  I already have outgoing mail 
> segregated how I want it when it exits my content filtering (ready to be sent 
> out).  So ideally, the content filter (actually the specialized smtpd process 
> that accepts mail from the content filter) could hand off to a specific smtp 
> process that has the needed smtp_bind_address.  

The smtpd process does not choose the smtp process. 

This quote from RELEASE_NOTES-2.7 describes two solutions that may
be of interest: see Feature 20100117 and Feature 20091209 below.

Feature 20091209 triggers only on the envelope sender address,
while Feature 20100117 can trigger on any message property including
a string in the header or body. 

Both require that mail is split into classes, and all mail in class
X is sent out from an SMTP client IP address that is reserved for
class X. For each class you configure master.cf one Postfix SMTP
client for each SMTP source IP address, where each client has its
own "-o myhostname" and "-o smtp_bind_address" settings.

/etc/postfix/master.cf:
smtp1  unix  -   -   n   -   -   smtp
-o smtp_bind_address=192.168.1.1 -o myhostname=hostname1
smtp2  unix  -   -   n   -   -   smtp
-o smtp_bind_address=192.168.1.2 -o myhostname=hostname2

With Feature 20100117 you'd specify actions of "FILTER smtp1:" or
"FILTER smtp2:" in an smtpd access(5) table, header_checks(5) or
body_checks(5). For example, in an access table:

/etc/postfix/main.cf:
smtpd_sender_restrictions =
check_sender_accesss hash:/etc/postfix/sender_access

/etc/postfix/sender_access:
sender1 FILTER smtp1:
sender2 FILTER smtp2:

With Feature 20091209 you'd have:

/etc/postfix/main.cf:
sender_dependent_default_transport_maps = 
hash:/etc/postfix/sender_transport

/etc/postfix/sender_transport:
sender1 smtp1
sender2 smtp2

Wietse

Major changes - sender reputation
-

[Feature 20100117] The FILTER action in access maps or header/body_checks
now supports sender reputation schemes that dynamically choose the
SMTP source IP address. Typically, mail is split into classes, and
all mail in class X is sent out from an SMTP client IP address that
is reserved for class X.

This is implemented by specifying FILTER actions with empty next-hop
destinations in access maps or header/body_checks, and by configuring
in master.cf one Postfix SMTP client for each SMTP source IP address,
where each client has its own "-o myhostname" and "-o smtp_bind_address"
settings.

[Feature 20091209] sender_dependent_default_transport_maps, a
per-sender override for default_transport. The original motivation
is to use different output channels (with different source IP
addresses) for different sender addresses, in order to keep their
IP-based reputations separate from each other.

The result value syntax is that of default_transport, not transport_maps.
Thus, sender_dependent_default_transport_maps does not support the
special transport_maps result value syntax for null transport, null
nexthop, or null email address.

Re: Sending on different network interface

[email builder]

> On Sun, Apr 03, 2011 at 10:39:58PM -0700, email builder wrote:

> > I'm  wondering if it's possible to configure a smtpd process in 
> > master.cf to send messages to the  outside on a secondary network 
> > interface.
> 
> Of course not;  smtpd(8) is the SMTP daemon, the server. It receives 
> mail; it does not send  it. Sending is done by smtp(8), the SMTP 
> client.

Sorry for mucking up terminology.  Indeed, I goofed that one.

> > It seems to be  possible to make a smtpd process listen on a given 
> > interface (IP  address) by specifying the IP address on the front of 
> > the configuration  line like so (where "bbb.bbb.bbb.bbb" is an IP 
> > address affixed to a  secondary network interface):
> > 
> > bbb.bbb.bbb.bbb:smtps inet   n  -  n  -   -  smtpd
> 
> Right.
> 
> > But when sending  mail, it still seems to go out on the machine's 
> > primary network  interface.
> 
> Also right as per above. OVERVIEW.html might be of  interest.
> 
> > Help much appreciated.
> 
> See  postconf.5.html#smtp_bind_address for the setting which controls 
> smtp(8)'s  selection of IP address. Google this mailing list for that, 
> and you will  find many examples.
> 
> See postconf.5.html#transport_maps (and  transport.5.html for the 
> syntax thereof) for the basic means to override  default selections of 
> outgoing mail transport.

OK, thank you very much for the pointer to smtp_bind_address.  That's what I 
need, but I'm stumbling at the transport map.  I already have outgoing mail 
segregated how I want it when it exits my content filtering (ready to be sent 
out).  So ideally, the content filter (actually the specialized smtpd process 
that accepts mail from the content filter) could hand off to a specific smtp 
process that has the needed smtp_bind_address.  


But from what I can tell, I can't control that -- the transport map seems to be 
the only gateway for choosing the outgoing smtp process.  I'd prefer not to 
maintain more than one transport map, so is there *any other way* for a smtpd 
process to indicate which smtp process to use?

I guess since transport_maps accepts more than one map, for each segregated 
mail 
group (smtpd process that accepts mail from my content filter), I can point to 
BOTH my normal transport map (same for everybody) AND a simple (single entry 
(which is a wildcard pointing to the desired smtp process)) map that is 
specific 
to each group.

I'm supposing that'd work.  Since the additional map will contain just a 
single, 
wildcard entry, is there any map type that is more simple/faster than a 
file-based table?


Stepping back, is there a better way to control choice of outgoing smtp process 
without relying on transport_maps?


> In your example, you  mentioned smtps, port 465. Be aware that Postfix 
> has no native  implementation of TLS "wrappermode" for the SMTP 
> client. A workaround using  stunnel(1) can be found in the 
> TLS_README.html document.

smtpd_sender_restrictions for alias?

[Jonas H.]

I'm using Postfix aliases for a small mailing list. I'd like to make 
sure only a few e-mail addresses can post, so I found this 
smtpd_sender_restrictions thing. However, I couldn't find out if one can 
use that for a single alias? If not, is there any other way to 
accomplish this?


Thanks,
Jonas

Re: Postfix - delay_warning_time

[Ralf Hildebrandt]

* postfix :
> Hi 
> 
> How can tell me why the "delay_warning_time" parameter is set to 0 per
> default?
> ( traffic increase risk?)

Users usually don't understand these messages :)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Postfix - delay_warning_time

[postfix]

Hi 

How can tell me why the "delay_warning_time" parameter is set to 0 per
default?
( traffic increase risk?)

Thank You
Alain

sender and recipient check on submit server

[Gábor Lénárt]

Hi,

I have a mail submit server for our users. What I would like is checking
sender and rcpt addresses if they belong to the domains at least which are
handled by us (of course I can't check if mail is sent to another domain
where I don't know the valid addresses, and I don't want to do SAV).

I have valid addresses and our domain list in LDAP. What made me thing that
it's possible at all to do this without a custom policy server:

1. check if domain part of the address is listed as our domain in LDAP
   if not, there is no further check by address validation (well, just the
   usual DNS ones)
2. if mailing of domain is handled by us, check if there is an address
   like "localpart@domain" or "@domain" (the second form is used to signal
   that all localparts are valid within that domain, ie: user has own MTA
   or so). If there is no match, I want to reject the mail submission.
3. Of course I want my users to use SMTP authentication (it works,
   using dovecot auth, just I mention here). Also some users may allowed
   to send mails without SMTP authentication from some well defined IP
   addresses though (also stored in LDAP).

I used the notion of "address" because I would like to have the same check
for rcpt and sender, because it also does not make too much sense to use
an invalid sender (not existing within the domain handled by us). Point 3 is
only an additional information, the important part is 1+2.

Of course I can do basic ldap lookups with postfix, but I am not sure it's
possible at all, to have more complex conditions, I mean: loc@domain can
be valid or invalid based on the fact that "domain" is handled by us or not.
So basically I need at least two queries it seems: if we handle a given
domain then: if it is, is the "loc" local part is valid or not.

Additional information: I would like to do this with only ldap maps at smtpd
sender and recipient restrictions (not with postfix's rcpt/sender maps etc),
since I want my own messages (including Hungarian) not postfix's built-in
ones.  Is it possble, or should I write a policy server instead? Or am I
wrong somewhere in my theory about solving this problem? (on long term I
have the idea to use _only_ policy server to decide, since I can use SQL
based logging from the policy server at every protocol state, I can do
custom complicated queries and conditions, also I can use my own messages
everywhere, etc. But for now there would be cool to have some more quick
solution for the problem I've described).

Thanks a lot in advance,

Gábor

Re: Configuring TLS with sender login maps

[Ansgar Wiechers]

On 2011-04-02 Reindl Harald wrote:
> Am 02.04.2011 23:17, schrieb Jeroen Geilman:
>> I see Mr Reindl is butting his big mouth in again
> 
> is your toilet broken or why is your neck so big?

You've repeatedly shown an attitude on this list that I consider
objectionable, to say the least. Would you mind keeping it to yourself?
Thank you.

>> I "should" do nothing.
> 
> YOU can do waht you want, but do not recommend others wrong things

He didn't.

[...]
>> Because the primary value of TLS on a mail client is to be able to
>> send encrypted login information, and prevent sniffing on local LAN
>> networks
> 
> *lol*
> 
> you know about cram-md5 / digest-md5
> this is for login-information

You do realize that these have other disadvantages, don't you? Like the
requirement to store the user's unencrypted password on the server.

[...]
>> I can only repeat that your preposterous "SHOULD" demands are silly.
>> Guaranteed end-to-end encryption is not a job for the MTA.
>> Use PGP or GPG to achieve message confidentiality.
> 
> you were the who spoke about "the majority"?
> the majority is not using GPG!

Which doesn't change anything about the fact that PGP/GPG is suited for
ensuring end-to-end confidentiality, while TLS is not. TLS only ever
guarantees encrypted transmission to the next HOP. Period. Live with it.

Regards
Ansgar Wiechers
-- 
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

Re: Sending on different network interface

[Robert Schetterer]

Am 04.04.2011 07:39, schrieb email builder:
> Hello,
> 
> I'm wondering if it's possible to configure a smtpd process in master.cf to 
> send 
> messages to the outside on a secondary network interface.  It seems to be 
> possible to make a smtpd process listen on a given interface (IP address) by 
> specifying the IP address on the front of the configuration line like so 
> (where 
> "bbb.bbb.bbb.bbb" is an IP address affixed to a secondary network interface):
> 
> bbb.bbb.bbb.bbb:smtps inet  n  -  n  -  -  smtpd
> 
> But when sending mail, it still seems to go out on the machine's primary 
> network 
> interface.
> 
> Help much appreciated.

you may use
smtp_bind_address=your.ip.add.here
in main.cf

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria