destination_concurrency_limit to relayhost only
Hi, Our postfix server serves several internal domains and relays outgoing traffic through our ISP SMTP relay server. This external SMTP server is limited to 3 destination domains at the same time. I am wondering if it is possible to set a destination_concurrency_limit of 3 to the relayhost SMTP server *only* and use the default limit for others SMTP servers. I know I can set this limit per domain using a transport map but i have to apply the limit to only a specific host : the relayhost. I'm running postfix 2.9.1 on RHEL 6.3 Thanks for your replies, Victor
smtpd_sender_login_maps
Hello, I check the sender address of authenticated users: smtpd_sender_login_maps = ldap:/path/to/postfix/ldapsender.cf smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch, permit_sasl_authenticated, permit_mynetworks This works like expected. But, now I would like to enable one special authenticated user to send mails with any (valid) sender addresses of any other (valid) user. mailuser authenticates as mailuser and its sender address is valid: mailu...@mydomain.de . OK. specialuser authenticates as specialuser and it should be possible for him to use mailu...@mydomain.de as a sender address. Is this possible and how can I configure this? Thank you. P.
Re: Send mails use the same source IP across multiple servers
Wietse: > 2) Use a SOCKS server for one or more dedicated external source IP > addresses. This would require an extension of the SOCKS protocol > such that the Postfix SMTP client can specify both the local and > the remote IP address for a connection. Ram: > Option 2 seems perfect > Please is there a SMTP over socks example somewhere I can use ? I am not > able to find any You won't find any. SOCKS is most often used in combination with other protocols. Nor do I expect that anyone has implemented an extension to specify both source and destination IP addresses. This isn't rocket science, but the use case is so rare that I can't justify investing time into it. Wietse
Re: RBL 'weighting'?
Miha Valencic: > Hi! > > Is it possible to add-up scores from different RBL's and reject the > incoming message after a certain threshold? Only with postscreen(8). This will not be implemented in smtpd_mumble_restrictions. http://www.postfix.org/POSTSCREEN_README.html http://www.postfix.org/postscreen.8.html Wietse
Re: RBL 'weighting'?
On 12/17/2012 7:40 AM, Miha Valencic wrote: > Hi! > > Is it possible to add-up scores from different RBL's and reject the > incoming message after a certain threshold? > > For instance, we have a number of RBLs configured and would like to > reject email only after a couple of RBLs fail verification. > > Thanks, > Miha. > The postfix "postscreen" feature has RBL weighing built in. http://www.postfix.org/POSTSCREEN_README.html http://www.postfix.org/postscreen.8.html http://www.postfix.org/postconf.5.html#postscreen_dnsbl_sites http://www.postfix.org/postconf.5.html#postscreen_dnsbl_threshold If you can't or don't want to use postscreen, you can use an external policy service, such as policyd-weight or postfwd, which will give you more flexible access control. http://www.postfix.org/SMTPD_POLICY_README.html http://www.postfix.org/addon.html#policy -- Noel Jones
Re: RBL 'weighting'?
Wietse, Noel, thanks for the prompt answers. I've been already looking at postscreen and postfwd, but wandered if there something in the postfix *_restrictions as well. We're using postfix 2.7, so postscreen is out. We're looking into implementing policyd anyway, so that's probably a good place. Kind regards, Miha. On Mon, Dec 17, 2012 at 3:00 PM, Wietse Venema wrote: > Only with postscreen(8). This will not be implemented in > smtpd_mumble_restrictions.
Re: RBL 'weighting'?
Miha Valencic skrev den 17-12-2012 14:40: Is it possible to add-up scores from different RBL's and reject the incoming message after a certain threshold? sounds like policyd-weight For instance, we have a number of RBLs configured and would like to reject email only after a couple of RBLs fail verification. but postfix with postscreen enabled can do this aswell, just not what postscreen was intended to do, so start with policyd-weight first
Re: RBL 'weighting'?
On Mon, Dec 17, 2012 at 04:39:36PM +0100, Benny Pedersen wrote: > Miha Valencic skrev den 17-12-2012 14:40: > > >Is it possible to add-up scores from different RBL's and reject the > >incoming message after a certain threshold? > > sounds like policyd-weight > > >For instance, we have a number of RBLs configured and would like to > >reject email only after a couple of RBLs fail verification. > > but postfix with postscreen enabled can do this aswell, just not > what postscreen was intended to do, so start with policyd-weight > first Policyd-weight is deprecated and doesn't even have async DNS lookups etc. Postfwd has replaced all that.
Re: RBL 'weighting'?
So, since we need some features of policyd as well (rate limiting, for instance), and we're already using amavis, do we chain postfwd before policyd or vice-versa? Thanks, Miha. On Mon, Dec 17, 2012 at 4:47 PM, Henrik K wrote: > Policyd-weight is deprecated and doesn't even have async DNS lookups etc. > Postfwd has replaced all that.
Re: RBL 'weighting'?
On 12/17/2012 10:52 AM, Miha Valencic wrote: > So, since we need some features of policyd as well (rate limiting, for > instance), and we're already using amavis, do we chain postfwd before > policyd or vice-versa? > > Thanks, > Miha. postfwd does rate limiting, and many other features. Maybe you can consolidate everything into postfwd. Additionally, rate limiting is typically done on outgoing mail, while RBL checks are typically for inbound mail. This might be a good time to investigate multiple postfix instances to separate your traffic flow. http://www.postfix.org/MULTI_INSTANCE_README.html Anyway, to answer your question about which to use first; it probably doesn't matter. Rule-of-thumb is to put less expensive checks first -- that suggests rate limits with local table lookups first, then the more time-consuming RBL lookups next. But in this situation it probably doesn't make much difference since they are checking different mail flows. -- Noel Jones
SMTP vs Submission
For various reasons it has been decided that internal users will only be allowed to use IMAPS/Submiission for email. Our setup is a fairly conventional Postfix/Dovecot/Amavis/... on Debian/Ubuntu. q1) am i correct in assuming that the smtpd section of main.cf is aimed at SMTP (tcp port 25) and the the "submission" section in master.cf is aimed at TCP port 587. q2) is it possible (or desirable) to deign staff the ability to send via port 25, while allowing the rest of the world to send to port 25. and the obverse is it possible to allow only staff access to port 587. I remember seeing an article that proposed such a setup, however Google has not been my friend this time. I have not included either postconf -n or master, but I can if they would help. Help would be appreciated. -- "He who opens a school door, closes a prison" - Victor Hugo Sent using Mozilla Thunderbird
Re: SMTP vs Submission
On 17/12/2012 1:54 PM, John Allen wrote: For various reasons it has been decided that internal users will only be allowed to use IMAPS/Submiission for email. Our setup is a fairly conventional Postfix/Dovecot/Amavis/... on Debian/Ubuntu. q1) am i correct in assuming that the smtpd section of main.cf is aimed at SMTP (tcp port 25) and the the "submission" section in master.cf is aimed at TCP port 587. q2) is it possible (or desirable) to deign staff the ability to send via port 25, while allowing the rest of the world to send to port 25. and the obverse is it possible to allow only staff access to port 587. deign -> deny I remember seeing an article that proposed such a setup, however Google has not been my friend this time. I have not included either postconf -n or master, but I can if they would help. Help would be appreciated. -- "He who opens a school door, closes a prison" - Victor Hugo Sent using Mozilla Thunderbird -- "He who opens a school door closes a prison" - Victor Hugo Sent using Mozilla Thunderbird
Re: RBL 'weighting'?
On Mon, Dec 17, 2012 at 7:13 PM, Noel Jones wrote: > postfwd does rate limiting, and many other features. Maybe you can > consolidate everything into postfwd. We'll take a deeper look at postfwd for that. > Additionally, rate limiting is typically done on outgoing mail, True. But there are some specific requirements (beyond my understanding :(). But if the setup will not be identical, we'll have to look into the multi-postfix setup again. Miha
Re: RBL 'weighting'?
On Mon, Dec 17, 2012 at 04:01:58PM +0100, Miha Valencic wrote: > We're using postfix 2.7, so postscreen is out. Actually not. You could build 2.8 and bring in the postscreen and dnsblog executables and master.cf configuration; this should work according to: http://www.postfix.org/announcements/postfix-2.7.0.html But then, you might as well just build and use 2.9. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: SMTP vs Submission
On Mon, Dec 17, 2012 at 01:54:59PM -0500, John Allen wrote: > For various reasons it has been decided that internal users will > only be allowed to use IMAPS/Submiission for email. > Our setup is a fairly conventional Postfix/Dovecot/Amavis/... on > Debian/Ubuntu. > q1) am i correct in assuming that the smtpd section of main.cf is > aimed at SMTP (tcp port 25) and the the "submission" section in > master.cf is aimed at TCP port 587. Not exactly. Your main.cf smtpd_* settings are the global defaults for all smtpd processes. You override those defaults for submission using -o override options. > q2) is it possible (or desirable) to deny staff the ability to > send via port 25, while allowing the rest of the world to send > to port 25. and the obverse is it possible to allow only staff > access to port 587. Sure. Simply do not include any permit_* restrictions in main.cf (global) smtpd_recipient_restrictions. Override this with simple submission_recipient_restrictions for submission: main.cf : smtpd_recipient_restrictions = [ ... nothing with permit ... ],] reject_unauth_destination[, et c. ] # smtpd_sasl_auth_enable not set # this could optionally include permit_mynetworks if desired submission_recipient_restrictions = permit_sasl_authenticated, reject master.cf : submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=$submission_recipient_restrictions -o syslog_name=postfix/submission -o milter_macro_daemon_name=ORIGINATING This would, however, allow any of your own senders to reach your recipients on port 25, assuming they passed any spam checks you impose. This may or may not be a problem. It can be tightened up further by use of smtpd_sender_login_maps and requiring AUTH with reject_unauthenticated_sender_login_mismatch in the global smtpd_recipient_restrictions. (Remember, you're not even offering AUTH on port 25, so senders cannot AUTH.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: smtpd_sender_login_maps
On Mon, Dec 17, 2012 at 11:11:02AM +0100, Petra Humann wrote: > I check the sender address of authenticated users: > > >smtpd_sender_login_maps = ldap:/path/to/postfix/ldapsender.cf > >smtpd_sender_restrictions = > >reject_authenticated_sender_login_mismatch, > >permit_sasl_authenticated, permit_mynetworks > > > This works like expected. > > But, now I would like to enable one special authenticated user > to send mails with any (valid) sender addresses of any other > (valid) user. > > mailuser authenticates as mailuser and its sender address is > valid: > mailu...@mydomain.de. OK. > specialuser authenticates as specialuser and it should be > possible for him to use > mailu...@mydomain.de as a sender address. > Is this possible and how can I configure this? One way is to manually configure your smtpd_sender_login_maps to return also "specialuser" for every valid address. Perhaps this is easily done with your ldap_table(5) by means of "result_format"? /path/to/postfix/ldapsender.cf : ... result_format = %s,specialuser -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: SMTP vs Submission - closed
On 17/12/2012 3:03 PM, /dev/rob0 wrote: On Mon, Dec 17, 2012 at 01:54:59PM -0500, John Allen wrote: For various reasons it has been decided that internal users will only be allowed to use IMAPS/Submiission for email. Our setup is a fairly conventional Postfix/Dovecot/Amavis/... on Debian/Ubuntu. q1) am i correct in assuming that the smtpd section of main.cf is aimed at SMTP (tcp port 25) and the the "submission" section in master.cf is aimed at TCP port 587. Not exactly. Your main.cf smtpd_* settings are the global defaults for all smtpd processes. You override those defaults for submission using -o override options. It is obvious how it works, once someone points it out. Thanks for the explanation, its a great help and makes a number of other things clearer. q2) is it possible (or desirable) to deny staff the ability to send via port 25, while allowing the rest of the world to send to port 25. and the obverse is it possible to allow only staff access to port 587. Sure. Simply do not include any permit_* restrictions in main.cf (global) smtpd_recipient_restrictions. Override this with simple submission_recipient_restrictions for submission: main.cf : smtpd_recipient_restrictions = [ ... nothing with permit ... ],] reject_unauth_destination[, et c. ] # smtpd_sasl_auth_enable not set # this could optionally include permit_mynetworks if desired submission_recipient_restrictions = permit_sasl_authenticated, reject master.cf : submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=$submission_recipient_restrictions -o syslog_name=postfix/submission -o milter_macro_daemon_name=ORIGINATING This would, however, allow any of your own senders to reach your recipients on port 25, assuming they passed any spam checks you impose. This may or may not be a problem. It can be tightened up further by use of smtpd_sender_login_maps and requiring AUTH with reject_unauthenticated_sender_login_mismatch in the global smtpd_recipient_restrictions. (Remember, you're not even offering AUTH on port 25, so senders cannot AUTH.) I have come to the conclusion that the whole basis for my question is/was stupid. The idea of restricting staff to IMAP/submission is a policy problem not a technical one. Thread Closed -- "He who opens a school door, closes a prison" - Victor Hugo Sent using Mozilla Thunderbird
