| |||||||||||||||||||||||||||||||
|
> Hi Mouss & postfixers folks, > > One question about the solution you've found before applying it : > >> mouss wrote: >>> smtpd_recipient_restrictions = >>> ... >>> reject_unauth_destination >>> # allow our gateway >>> check_client_access cidr:/etc/postfix/trusted_client >>> # block mail to main domain >>> check_recipient_access hash:/etc/postfix/block_main_domain >>> ... >>> >>> >>> == trusted_client: >>> 10.1.2.0/24 OK >>> >>> == block_main_domain: >>> main.example.com REJECT >>> >>> >>> In short: >>> 1. if it is our gateway, allow >>> 2. if it is to main domain, block (the gateway was allowed in step 1) > > > What if a single mail is addressed to both my main domain and another > one I host too ? > e.g. An external mail w/ RCPT TO: user, > user2 > > Will postfix split the source into 2 separated mails then apply > smtpd_recipient_restrictions checks ? > > If not, this mail directly reaching my postfix w/o using the gateway > will not match rule #1, > and how will it deal with rule #2 ? > smtpd restrictions apply to each RCPT TO command (separately). In short, the client will send an "RCPT TO:<foo>" and before postfix replies, it performs the checks. then the client issues a second "RCPT TO..." etc. mail data comes later (after the DATA command). > I don't really know how to bench it and before applying this policy I'd > like to be sure no > bad border effects will occur... > connect from different IPs (one in the allowed list) and do # telnet server 25 EHLO client.example.org ... MAIL FROM:<postmaster> ... RCPT TO:<one> ... RCPT TO:<other> ... QUIT look at the response to the RCPT TO command. if you come from an unauthorized client, one of the RCPT TO will result in a reject. > Once more TIA for your hints. > > Regards, > > Laurent. > >
| ||||||||||||||||||||||||||||||
© 2004-2008 readlist.com