Re: too many postfix smtp active internet connections
* Clunk Werclick clunk.wercl...@wibblywobblyteapot.co.uk: On Mon, 2009-08-03 at 16:08 -0400, Wietse Venema wrote: Get rid of the backscatter: http://www.postfix.org/BACKSCATTER_README.html Wietse Has anybody implemented something like this with Postfix? http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation Any observations or advice? You need the milter capabilities from Postfix 2.6. Use the batv-milter. That's all I know at the moment. p...@rick -- All technical answers asked privately will be automatically answered on the list and archived for public access unless privacy is explicitely required and justified. saslfinger (debugging SMTP AUTH): http://postfix.state-of-mind.de/patrick.koetter/saslfinger/
Re: too many postfix smtp active internet connections
On Tue, 2009-08-04 at 08:12 +0200, Patrick Ben Koetter wrote: You need the milter capabilities from Postfix 2.6. Use the batv-milter. That's all I know at the moment. I am confused? batv-milter? Is it not pvrs? I see this: http://sourceforge.net/projects/batv-milter/ The idea looks very credible, and I have seen mails with pvrs= in the 'from' field. I think there is milter support in 2.5.5 (not just 2.6) as I have a clam milter running myself - but I am not so sure that this 'batv' milter would require something special to 2.6? -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.
Re: Postfix HELO FQDN requirement
/dev/rob0 wrote: On Monday 03 August 2009 07:58:48 Robin Smidsrød wrote: I'm just trying to figure out what to write in a policy document about this behaviour. A behaviour which is backed by a RFC has a lot of more weight (conserning interoperability) than our own policies about what is accepted behaviour or not. It's subjective. In my subjective experience, I have never seen a bad HELO (non-FQDN or invalid, or even valid bracketed [ip.add.re.ss]) delivering good mail. (YMMV if you don't know how to separate your users' submission from MX. MUAs often do EHLO with the bracketed [ip.add.re.ss] syntax. But no real MTA does it, IME.) All my servers/users are either listed in mynetworks or use sasl auth, and they go before any HELO reject rule, so they should be in the clear. When a legitimate server is rejected it is generally easier to say the admin of that server has not set up his server correctly according to the standard. Make him fix it if you want to receive email from them. than it is to say our policies does not allow a connection like that because the email is usually spam. The last one is a tempting reason for a customer to leave and find another service provider (because it Does this happen in the real world? Possibly. I've had at least one client leave because he absolutely needs to have every email, because every single email he receives could be really important. So dealing with spam is something he just has to do. On the other hand I have users that don't really care one way or the other. I just want to be able to let the user make that choice. And rejecting email based on (possibly forged) helo is a system-wide policy, not a user-specific policy. Is it possible to make this a user-policy? But what are the alternatives? Allow ALL the spam through, maybe doing some expensive content filtering which is slightly less accurate than pre-DATA checks (and far more prone to actual loss of mail, when users do not check their spam folders) -- or, block what you know to be garbage and take your chance with clueless customers and clueless competitors? Well, my way of dealing with the problem is to actually filter the email (statistical filtering) and let the user decide what they want to do with it (quarantine, tag or reject). That way I haven't taken the choice away from them. Yes it costs more (in terms of resources), but it makes it possible to cater to those clients that really don't want mail to be rejected. But seriously, reject_non_fqdn_helo_hostname and reject_invalid_helo_hostname are not likely to block real MX mail. Thanks for the clarifications. I've re-enabled them, ignored the whitelist (for now) to see how these rules actually pan out. reject_unknown_helo_hostname is still disabled. It was the main rule that required whitelisting in the first place. What does the reject_invalid_helo_hostname rule do with the IPv(4|6) HELO response? I mean, when the domain looks like [10.1.2.3] or [::1]? Does it accept or reject it? According to the RFC it should be valid. It IS valid. Invalid means not valid under RFC standards. However, again, I have never known a real MTA to use that syntax, only MUAs and spambots. I therefore made the policy decision to reject those (after permit_* restrictions.) Thanks for the clarification. I've re-enabled it to see if it blocks anything legitimate. reject_non_fqdn_helo_hostname means that the domain needs to contain at least a dot, and otherwise conform to the DNS naming standards, am I correct? Will this rule short-circuit *accept* a IPv4/6 domain, as defined above, or will it reject it? A bracketed [ip.add.re.ss] is not a non-FQDN HELO. Common ones I've seen include friend, and strings which appear to be infected Windows PC netbios names. Thanks again. Received lines are constructed the same way for all accepted mail, augmented only by some TLS settings. Is there any documentation for how it is constructed, or do I need to look in the source code? Regards, Robin, which is trying to build a mail system which puts the choice of rejecting/filtering email in the hands of the end user. While that sounds like a noble goal, I see lots of problems with it. Chief among those is the fact that end users often cannot distinguish spam from unwanted legitimate email. That doesn't really bother me so much. If it feels like spam to them they may classify it as such. It only influences the user himself. Of course, if they classify mailing lists as spam it will only fill up their junkmail box, which will just influence their allotted storage capacity (quota). I think mail administration needs much MORE professionalism (paternalism, you might even say), not less. I highly agree with you there. That is what I'm trying to build. A well documented, with clear policies, mail system which can cater to both of the user types mentioned above. -- Robin
Re: Question about address verification in MX2 when primary MX is down...
If you want this behavior, do not use reject_unverified*. Instead, use a relay_recipient_maps that can be checked locally. Hi. This server is a secondary MX server for our customers. Those customers have their own private primary MX servers, so It's not possible for me to have a local database of existing accounts. That's why I wanted to use reject_unverified_recipient, to let postfix guess if an account is valid or not using RCPT TO. And this behaviour is perfect, except when primary MX doesn't answer. It would be really perfect to be able to force postfix to accept the incoming emails when the dest address cannot be validated... Unless you have a really good reason, you'd be much better off just losing the MX2, Customers paying for MX BACKUP SERVER service is a good reason to not loose MX2 :-) Really, reject_unverified_recipient feature is very nice, but rejecting all mail when primary MX doesn't answers breaks it for us :( Any idea? :?
Re: Black magic rejecting header Subjects
Dear all
/dev/rob0 r...@gmx.co.uk [2009-08-03 23:05]:
On Monday 03 August 2009 15:34:59 Lukas Ruf wrote:
I cannot understand why Postfix/cleanup rejects particular Subject
lines, since I have been searching for the respective regexps but
haven't found what I've been looking for. My question is simple:
why are subject lines rejected that I cannot find definitions for?
Probably because they match expressions in your undisclosed [!!]
file of header_checks(5).
Please find attached the header_checks file currently in use:
When I comment the line in main.cf
header_checks = pcre:/etc/postfix/header_checks.pcre
everything works for me as expected. Thus, I strongly assume there
must be a bug somewhere in the definitions
Thanks for your support!
wbr,
Lukas
--
Lukas Ruf http://www.lpr.ch | Ad Personam
Consecom http://www.consecom.com | Ad Laborem
/^Content-Disposition: Multipart message/REJECT Multipart
message
/^received:.*/ REJECT Sorry, too many xxx
/^to:@public\.com$/ REJECT Sorry, this is not our domain!
/^(To|From):[[:space:]]*$/ REJECT Sorry no empty lines are accepted!
/^From:.*dealpatrol.com/ REJECT Sorry, not accepted
## /^Received: from .* by .*hotmail.com with DAV;/ REJECT Hotmail DAV submitted
Spam
#disallow all emails that have 5 or more non-printable characters in the header
/[^[:print:]]{5,}/ REJECT Your mailer is not RFC 2047 compliant
/^Subject: .*[^[:print:]]{8}/ REJECT Your mailer is not RFC 2047 compliant
# Control characters or too many 8-bit characters
#/[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x9f\xff]/ REJECT Sorry too many 8-bit
characters
# /(?:[a-z0-9]?[\x80-\xff]){6,}/ REJECT Sorry too many 8-bit
characters
## /^Received: by mail.topsy.net/IGNORE
## /^Delivered-To: @topsy.net/ IGNORE
## /^Delivered-To: software-l...@topsy.net/ IGNORE
## /^Delivered-To: @lpr.ch/IGNORE
## /^Received: from uccellina.maremma.ch/IGNORE
## /^Delivered-To: rawip-l...@topsy.net/ IGNORE
# BEGIN: ACTIVATE MAILSCANNER
# /^Received: from / HOLD
# END: ACTIVATE MAILSCANNER
#===
# This is the access filter file for mail.securitysage.com, published by
SecuritySage
# This filter is the work of Jeffrey Posluns j...@posluns.com
# For the latest header_checks file, please see
http://www.securitysage.com/files/header_checks
# For the latest body_checks file, please see
http://www.securitysage.com/files/body_checks
# For the latest access file, please see
http://www.securitysage.com/files/access
# Some people have asked how to set up a localhost instance of postfix that
will ignore any header and
# body checks. To do so, add the following to your master.cf file and change
the port number to whatever
# you want. You'll also probably want to change the myhostname to something
reflecting your system's hostname.
# Remember that there will be a header with that hostname appearing in any mail
you send or receive through
# this new instance of postfix. I would recommend that before restarting
postfix with the new instance that
# you start tailing your mail log to watch for any errors.
# 127.0.0.1:26 inet n - n - 100 smtpd -o content_filter= -o
myhostname=injector.securitysage.com -o mynetworks=127.0.0.0/8 -o
smtpd_client_restrictions= -o smtpd_helo_restrictions= -o
smtpd_sender_restrictions= -o
smtpd_recipient_restrictions=permit_mynetworks,reject -o header_checks= -o
body_checks=
# We use the header_checks file to remove some headers that we find undesirable.
# For more information, please see
http://www.securitysage.com/guides/postfix_anonym.html
#/^Disposition-Notification-To:/IGNORE # This drops return
receipts
#/^Received: from 127.0.0.1/IGNORE # This drops inline
AntiVirus scan headers
#/^User-Agent:/ IGNORE # This drops the name
of the mail program people use
#/^X-Mailer:/ IGNORE # This drops the mailer
or MTA program name on some systems
#/^X-MimeOLE:/ IGNORE # This drops the MIME
type header
#/^X-MSMail-Priority:/ IGNORE # This drops the
Microsoft priority tag header
#/^X-Originating-IP:/ IGNORE # This drops the
originating IP address header
#/^X-Sanitizer:/IGNORE # This drops the Anomy
sanitizer header
#/^X-Spam-Level:/ IGNORE # This drops the
SpamAssassin spam level header
#/^X-Spam-Status:/ IGNORE # This drops the
SpamAssassin spam status header
# Below are the active header removal lines:
/^Disposition-Notification-To:/ IGNORE
# Following Will Block Spams That Add Three Spaces Between Letters In Order To
Bypass Spam Filters
# This will
New Antispam settings
Hello, I'm trying to adjust my current antispam measures as they are no longer working. I'm running postfix 2.3 on a rel5 machine. I've got the below, which is a postconf -n output of my current configuration. To it i'd like to add spf, and postgrey support in smtpd_recipient_restrictions after the rbl checks, and dkim-milter last in the file. I'd appreciate any feedback on these settings and suggested improvements if any. Thanks. Dave. address_verify_map = btree:/var/spool/postfix/verified_senders alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases biff = no broken_sasl_auth_clients = yes canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix disable_vrfy_command = yes empty_address_recipient = MAILER-DAEMON home_mailbox = Maildir/ html_directory = no inet_interfaces = 127.0.0.1, External IP invalid_hostname_reject_code = 554 local_recipient_maps = proxy:unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_size_limit = 104857600 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 20971520 multi_recipient_bounce_reject_code = 554 mydomain = example.com myhostname = mail.example.com mynetworks = 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_fqdn_reject_code = 554 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES recipient_delimiter = + relay_domains_reject_code = 554 sample_directory = /usr/share/doc/postfix-2.3.3/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop show_user_unknown_table_name = no smtp_helo_timeout = 60s smtpd_banner = $myhostname smtpd_data_restrictions = reject_unauth_pipelining smtpd_error_sleep_time = 5s smtpd_hard_error_limit = 20 smtpd_helo_required = yes smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unverified_sender reject_unverified_recipient reject_multi_recipient_bounce, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_sender_mx_access cidr:/etc/postfix/bogus_mx check_recipient_access hash:/etc/postfix/recipient_access check_client_access hash:/etc/postfix/client_checks,check_client_access pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org, reject_rbl_client black.uribl.com, reject_rbl_client combined.rbl.msrbl.net, reject_rhsbl_sender dsn.rfc-ignorant.org smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_soft_error_limit = 10 smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/ssl/smtp.crt smtpd_tls_CAfile = /etc/postfix/ssl/ca-cert.pem smtpd_tls_key_file = /etc/postfix/ssl/smtp.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_cache smtpd_tls_session_cache_timeout = 3600s strict_rfc821_envelopes = yes tls_random_source = dev:/dev/urandom unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 unknown_relay_recipient_reject_code = 554 unknown_virtual_alias_reject_code = 554 unknown_virtual_mailbox_reject_code = 554 unverified_recipient_reject_code = 554 unverified_sender_reject_code = 554 virtual_alias_maps = hash:/etc/postfix/virtual_alias virtual_gid_maps = static:5000 virtual_mailbox_base = /home/vmail virtual_mailbox_domains = /etc/postfix/vhosts virtual_mailbox_maps = hash:/etc/postfix/vmaps virtual_minimum_uid = 1000 virtual_uid_maps = static:5000
Re: Postfix HELO FQDN requirement
Robin Smidsrød wrote: I've had at least one client leave because he absolutely needs to have every email, because every single email he receives could be really important. So dealing with spam is something he just has to do. On the other hand I have users that don't really care one way or the other. I just want to be able to let the user make that choice. And rejecting email based on (possibly forged) helo is a system-wide policy, not a user-specific policy. Is it possible to make this a user-policy? Hi Robin, It is possible to make rules user and/or domain dependant with carefully built restriction classes. If you haven't read this already, please do: http://www.postfix.org/RESTRICTION_CLASS_README.html The examples here are not exactly what you want, but you will get an idea of how you can build user / domain specific rules. HTH, Mikael
Re: Question about address verification in MX2 when primary MX is down...
Santiago Romero wrote: Really, reject_unverified_recipient feature is very nice, but rejecting all mail when primary MX doesn't answers breaks it for us :( Any idea? :? Hi, Quoting the documentation[1]: The unverified_recipient_defer_code parameter (default 450) specifies the numerical Postfix SMTP server reply code when a recipient address probe fails with some temporary error. Some sites insist on changing this into 250. NOTE: This change turns MX servers into backscatter sources when the load is high. So you are not rejecting any email if the MX is down. You are just delaying reject or accept until the MX is asked if there is such user or not. We're very happy with this over here. HTH, Mikael [1] http://www.postfix.org/ADDRESS_VERIFICATION_README.html
Re: Black magic rejecting header Subjects
Lukas Ruf wrote: Please find attached the header_checks file currently in use: When I comment the line in main.cf header_checks = pcre:/etc/postfix/header_checks.pcre everything works for me as expected. Thus, I strongly assume there must be a bug somewhere in the definitions /^X-Mailer: MIME\:\:Lite/ REJECT I use this one in my Perl mail applications. It's a legitimate CPAN module (see http://search.cpan.org/perldoc?MIME::Lite) that is quite popular. Blocking it will probably reject a lot of email from scripts (of various nature, some probably spam, some not). -- Robin
Re: New Antispam settings
On Tue, 2009-08-04 at 04:17 -0400, Dave wrote: Hello, I'm trying to adjust my current antispam measures as they are no longer working. I'm running postfix 2.3 on a rel5 machine. I've got the below, which is a postconf -n output of my current configuration. To it i'd like to add spf, and postgrey support in smtpd_recipient_restrictions after the rbl checks, and dkim-milter last in the file. I'd appreciate any feedback on these settings and suggested improvements if any. Thanks. Dave. address_verify_map = btree:/var/spool/postfix/verified_senders alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases biff = no broken_sasl_auth_clients = yes canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix disable_vrfy_command = yes empty_address_recipient = MAILER-DAEMON home_mailbox = Maildir/ html_directory = no inet_interfaces = 127.0.0.1, External IP invalid_hostname_reject_code = 554 local_recipient_maps = proxy:unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_size_limit = 104857600 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 20971520 multi_recipient_bounce_reject_code = 554 mydomain = example.com myhostname = mail.example.com mynetworks = 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_fqdn_reject_code = 554 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES recipient_delimiter = + relay_domains_reject_code = 554 sample_directory = /usr/share/doc/postfix-2.3.3/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop show_user_unknown_table_name = no smtp_helo_timeout = 60s smtpd_banner = $myhostname smtpd_data_restrictions = reject_unauth_pipelining smtpd_error_sleep_time = 5s smtpd_hard_error_limit = 20 smtpd_helo_required = yes smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unverified_sender reject_unverified_recipient reject_multi_recipient_bounce, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination,check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks,check_sender_access hash:/etc/postfix/sender_checks, check_sender_mx_access cidr:/etc/postfix/bogus_mx check_recipient_access hash:/etc/postfix/recipient_accesscheck_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org, reject_rbl_client black.uribl.com, reject_rbl_client combined.rbl.msrbl.net, reject_rhsbl_sender dsn.rfc-ignorant.org smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_soft_error_limit = 10 smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/ssl/smtp.crt smtpd_tls_CAfile = /etc/postfix/ssl/ca-cert.pem smtpd_tls_key_file = /etc/postfix/ssl/smtp.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_cache smtpd_tls_session_cache_timeout = 3600s strict_rfc821_envelopes = yes tls_random_source = dev:/dev/urandom unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 unknown_relay_recipient_reject_code = 554 unknown_virtual_alias_reject_code = 554 unknown_virtual_mailbox_reject_code = 554 unverified_recipient_reject_code = 554 unverified_sender_reject_code = 554 virtual_alias_maps = hash:/etc/postfix/virtual_alias virtual_gid_maps = static:5000 virtual_mailbox_base = /home/vmail virtual_mailbox_domains = /etc/postfix/vhosts virtual_mailbox_maps = hash:/etc/postfix/vmaps virtual_minimum_uid = 1000 virtual_uid_maps = static:5000 Postgrey is a reasonable suggestion, but I don't tend to like allowing repeat connections myself. I like to do a simple 'yes or no' and not beat the bush around. If I may comment about your usage of DKIM SPF. Many many people, even legitimate senders, don't have DKIM or SPF. So implementation would almost certainly be carnage for lots of your HAM if you decide to block on this criteria. SPF DKIM are really only useful for white listing IMHO. What kind of spam is failing to get caught? Perhaps get Postfix to work with Spamassassin or put in some basic header/body checks to catch obvious spams? -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail
Re: Postfix HELO FQDN requirement
Mikael Bak wrote: Robin Smidsrød wrote: I've had at least one client leave because he absolutely needs to have every email, because every single email he receives could be really important. So dealing with spam is something he just has to do. On the other hand I have users that don't really care one way or the other. I just want to be able to let the user make that choice. And rejecting email based on (possibly forged) helo is a system-wide policy, not a user-specific policy. Is it possible to make this a user-policy? It is possible to make rules user and/or domain dependant with carefully built restriction classes. If you haven't read this already, please do: http://www.postfix.org/RESTRICTION_CLASS_README.html Thanks for the link. It indeed explains how to make rules user-definable. Of course, to enable use of check_recipient_access in smtpd_helo_restrictions, smtpd_delay_reject must obviously be set to Yes (the default). -- Robin
Re: Black magic rejecting header Subjects
On Tue, 2009-08-04 at 11:44 +0200, Robin Smidsrød wrote: Lukas Ruf wrote: Please find attached the header_checks file currently in use: When I comment the line in main.cf header_checks = pcre:/etc/postfix/header_checks.pcre everything works for me as expected. Thus, I strongly assume there must be a bug somewhere in the definitions /^X-Mailer: MIME\:\:Lite/ REJECT I use this one in my Perl mail applications. It's a legitimate CPAN module (see http://search.cpan.org/perldoc?MIME::Lite) that is quite popular. Blocking it will probably reject a lot of email from scripts (of various nature, some probably spam, some not). -- Robin I too use it, but I changed the X-Mailer so it does not say 'MIME::Lite'. I am sure that spammers may think of that also? The people who write bots and spam scripts are very skilled - it would only be a child or rank amateur who would leave that silly header as it is. -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.
MsExchange --- Exim
Hello, I want to _change_ MsExchange to Postfix in my corporation. I have 150 users in my network. They work in Outlook 2003. We are using Active Directory to authentification. Could you tell me what is the consequencies of making that change. Especialy I would like to know: 1. Is Postfix cooperate with Active Directory or eDirectory? Anybody use Postfix with AD or eDirectory? 2. I know that communication between Exchange and Outlook is with MAPI protocol. Does Postfix use the MAPI protocol? 3. If 2 is no, Is Postfix POP or IMAP server? I would like to use POP or IMAP protocol instead MAPI. 4. Is this possible that Postfix has a Outlook calendar feature and other Outlook like feature. 5. Does Postfix support TLS, SSL? 6. Does Postfix support acces via http to mail box? Thanks pch0317
Exchange -- Postfix
Hello, I want to _change_ MsExchange to Postfix in my corporation. I have 150 users in my network. They work in Outlook 2003. We are using Active Directory to authentification. Could you tell me what is the consequencies of making that change. Especialy I would like to know: 1. Is Postfix cooperate with Active Directory or eDirectory? Anybody use Postfix with AD or eDirectory? 2. I know that communication between Exchange and Outlook is with MAPI protocol. Does Postfix use the MAPI protocol? 3. If 2 is no, Is Postfix POP or IMAP server? I would like to use POP or IMAP protocol instead MAPI. 4. Is this possible that Postfix has a Outlook calendar feature and other Outlook like feature. 5. Does Postfix support TLS, SSL? 6. Does Postfix support acces via http to mail box? Thanks pch0317
Re: Exchange -- Postfix
* Paweł Ch. pch0...@gmail.com: Hello, I want to _change_ MsExchange to Postfix in my corporation. I have 150 users in my network. They work in Outlook 2003. We are using Active Directory to authentification. Could you tell me what is the consequencies of making that change. Especialy I would like to know: 1. Is Postfix cooperate with Active Directory or eDirectory? Anybody use Postfix with AD or eDirectory? What part exactly needs to come from the AD? 2. I know that communication between Exchange and Outlook is with MAPI protocol. Does Postfix use the MAPI protocol? No. 3. If 2 is no, Is Postfix POP or IMAP server? I would like to use POP or IMAP protocol instead MAPI. Neither POP nor IMAP. Postfix is an SMTP server 4. Is this possible that Postfix has a Outlook calendar feature and other Outlook like feature. No. 5. Does Postfix support TLS, SSL? Yes. 6. Does Postfix support acces via http to mail box? No. Postfix is an SMTP server -- 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: Exchange -- Postfix
www.postfix.org www.google.com On Tue, Aug 4, 2009 at 11:53 AM, Paweł Ch.pch0...@gmail.com wrote: Hello, I want to _change_ MsExchange to Postfix in my corporation. I have 150 users in my network. They work in Outlook 2003. We are using Active Directory to authentification. Could you tell me what is the consequencies of making that change. Especialy I would like to know: 1. Is Postfix cooperate with Active Directory or eDirectory? Anybody use Postfix with AD or eDirectory? 2. I know that communication between Exchange and Outlook is with MAPI protocol. Does Postfix use the MAPI protocol? 3. If 2 is no, Is Postfix POP or IMAP server? I would like to use POP or IMAP protocol instead MAPI. 4. Is this possible that Postfix has a Outlook calendar feature and other Outlook like feature. 5. Does Postfix support TLS, SSL? 6. Does Postfix support acces via http to mail box? Thanks pch0317
Re: Exchange -- Postfix
Paweł Ch. schrieb: Hello, I want to _change_ MsExchange to Postfix in my corporation. I have 150 users in my network. They work in Outlook 2003. We are using Active Directory to authentification. Could you tell me what is the consequencies of making that change. Especialy I would like to know: 1. Is Postfix cooperate with Active Directory or eDirectory? Anybody use Postfix with AD or eDirectory? 2. I know that communication between Exchange and Outlook is with MAPI protocol. Does Postfix use the MAPI protocol? 3. If 2 is no, Is Postfix POP or IMAP server? I would like to use POP or IMAP protocol instead MAPI. 4. Is this possible that Postfix has a Outlook calendar feature and other Outlook like feature. 5. Does Postfix support TLS, SSL? 6. Does Postfix support acces via http to mail box? Thanks pch0317 in real world, postfix mostly is setup as incoming and/or outgoing smtp relayserver for exchange by high performance and cheap and best spam and antivirus filtering, postfix normally needs the valid recipient mail addresses ( and domains ) from the ad to to this job ( or at minimum address recipient validation), there are serveral strategies to make this kind of setup work, which does best, depends i.e on your local network setup, look google for examples how to use postfix relay with exchange if you wanna get off in total from exchange, without loosing groupware functions of exchange search for alternatives ( free and paid ) like kolab etc you may also use postfix/dovecot/horde/spamassassin/clamav to implement a free alternative to exchange ( if youre good you get a nearly cross platform working mail groupware alternative up to 90 % of the exchange features at last learn difference between smtp , pop3, imap, mapi, http etc and if you want to understand what are differences between exchange and others you should understand exchange and outlook first too, which is more difficult then clicking wizards on guis , this will give you the needed basics for make decisions -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
RE: Exchange -- Postfix
2. I know that communication between Exchange and Outlook is with MAPI protocol. Does Postfix use the MAPI protocol? 3. If 2 is no, Is Postfix POP or IMAP server? I would like to use POP or IMAP protocol instead MAPI. 4. Is this possible that Postfix has a Outlook calendar feature and other Outlook like feature. 5. Does Postfix support TLS, SSL? 6. Does Postfix support acces via http to mail box? You may want to look at Zarafa combined with Postfix and MySQL. It provides a client to use with Outlook (in a way just like Exchange does), it provides webaccess that looks like OWA/Outlook with working context menus (also in FF), POP, IMAP, etc. http://www.zarafa.com/ There's also a whitepaper about LDAP/AD integration in the website's documentation section. It's NOT free, but I guess it's certainly cheaper than Exchange (I just use the free community version that's limited to 5 users; you could use that to check out if Zarafa suits your needs). -- Rob
multiple relay hosts in transport - syntax
I would like to define two relay hosts for one domain in our transport map, the primary and backup MTX so postfix will try the backup if the primary does not respond. Is this possible and what would be my syntax? domain.com smtp:[pri-mx.domain.com] smtp:[bak-mx.domain.com] or domain.com smtp:[pri-mx.domain.com] [bak-mx.domain.com] or wrong all together...\ Thank you.
Re: multiple relay hosts in transport - syntax
* Andrew Long furs...@gmail.com: I would like to define two relay hosts for one domain in our transport map, the primary and backup MTX so postfix will try the backup if the primary does not respond. Is this possible and what would be my syntax? Use dns like: $ host -t mx charite.de charite.de mail is handled by 120 mail.charite.de. charite.de mail is handled by 110 mail-ausfall.charite.de. and then use: domain.de charite.de -- 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: Exchange -- Postfix
On Tue, Aug 4, 2009 at 5:53 AM, Paweł Ch.pch0...@gmail.com wrote: Hello, I want to _change_ MsExchange to Postfix in my corporation. I have 150 users in my network. They work in Outlook 2003. We are using Active Directory to authentification. Could you tell me what is the consequencies of making that change. Especialy I would like to know: 1. Is Postfix cooperate with Active Directory or eDirectory? Anybody use Postfix with AD or eDirectory? 2. I know that communication between Exchange and Outlook is with MAPI protocol. Does Postfix use the MAPI protocol? 3. If 2 is no, Is Postfix POP or IMAP server? I would like to use POP or IMAP protocol instead MAPI. 4. Is this possible that Postfix has a Outlook calendar feature and other Outlook like feature. 5. Does Postfix support TLS, SSL? 6. Does Postfix support acces via http to mail box? You posted an identical message in the Exim users groups with s/postfix/exim. Maybe you are a troll. Maybe you are too lazy to find this basic information for yourself. Either way, this seems like a waste of everyones time. Thanks pch0317
Re: multiple relay hosts in transport - syntax
$ host -t mx charite.de charite.de mail is handled by 120 mail.charite.de. charite.de mail is handled by 110 mail-ausfall.charite.de. and then use: domain.de charite.de I'm afraid I'm not quite clear on this. They're are two mx's in the dns for the domain, a la $ host -t mx domain.com domain.com mail is handled by 20 domain.com.bak-mx.smtpblah.com. domain.com mail is handled by 10 domain.com.pri-mx.smtpblah.com. so my transport would look like... what?
MsExchange --- Postfix
Thanks very much.
Re: multiple relay hosts in transport - syntax
* Andrew Long furs...@gmail.com: $ host -t mx charite.de charite.de mail is handled by 120 mail.charite.de. charite.de mail is handled by 110 mail-ausfall.charite.de. and then use: domain.de charite.de I'm afraid I'm not quite clear on this. They're are two mx's in the dns for the domain, a la $ host -t mx domain.com domain.com mail is handled by 20 domain.com.bak-mx.smtpblah.com. domain.com mail is handled by 10 domain.com.pri-mx.smtpblah.com. so my transport would look like... what? domain.comdomain.com -- 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: multiple relay hosts in transport - syntax
On Aug 4, 2009, at 8:31 AM, Andrew Long furs...@gmail.com wrote: $ host -t mx charite.de charite.de mail is handled by 120 mail.charite.de. charite.de mail is handled by 110 mail-ausfall.charite.de. and then use: domain.de charite.de I'm afraid I'm not quite clear on this. They're are two mx's in the dns for the domain, a la $ host -t mx domain.com domain.com mail is handled by 20 domain.com.bak-mx.smtpblah.com. domain.com mail is handled by 10 domain.com.pri-mx.smtpblah.com. so my transport would look like... what? It would look like Ralf already showed you. But if you are sending to example.org which has the two MX RRs, then there is no need to configure transport maps. If you do use transport maps, the lack of brackets around the nexthop means Postfix will use MX lookups when deciding which nexthop to choose. You CANNOT specify multiple nexthops in the sense you tried to in your original post.
Delivery failure for one recipient results in re-delivery for all
I'm having a problem with Postfix 2.4.6, built from source on Solaris 10. Locally delivered mail is placed in maildirs on an NFS-imported disk. The NFS server uses file system quotas. Using alias_maps, mail for root is sent to several users. When one of the expanded recipients goes over quota, Postfix successfully delivers the mail to all other expanded recipients and reports a failed delivery for the user who is over quota. The mail goes into the queue for another delivery attempt a few minutes later. However, what's queued seems to be the original (un-expanded) recipient, so at the next attempt, the alias is expanded again, and the users who are under quota get another copy, while the user that is over quota gets another failure, and the mail is re-queued again. And so it goes, around and around, until someone notices and increases the offending user's quota temporarily, allowing the deliveries to succeed completely and the queue to drain. How can I get Postfix to just re-attempt delivery to the user over quota, not the others? The sample below has a two-step alias expansion (syslog-all - root - user1,...), but the same happens for mail sent directly to root. aliases: syslog-all: root root: user1,useroverquota,user2,user3,user4,user5,user6,user7 A sample piece of mail in mailq: F03CF3B469 1092 Mon Aug 3 20:13:22 r...@example.com (maildir delivery failed: error writing message: Disc quota exceeded) useroverqu...@example.com syslog-...@example.com Syslog: Aug 4 00:14:08 ns1 postfix/smtpd[21102]: [ID 197553 mail.info] 775993B4F5: client=pc1.example.com[10.0.177.250] Aug 4 00:14:08 ns1 postfix/cleanup[21008]: [ID 197553 mail.info] 775993B4F5: message-id=200908032214.n73me812061...@pc1.example.com Aug 4 00:14:08 ns1 postfix/qmgr[665]: [ID 197553 mail.info] 775993B4F5: from=r...@example.com, size=5316, nrcpt=1 (queue active) Aug 4 00:14:08 ns1 postfix/local[21103]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=0.13, delays=0.09/0/0/0.04, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:14:08 ns1 postfix/local[21103]: [ID 197553 mail.info] 775993B4F5: to=useroverqu...@example.com, orig_to=syslog-...@example.com, relay=local, delay=0.18, delays=0.09/0/0/0.09, dsn=4.2.2, status=deferred (maildir delivery failed: error writing message: Disc quota exceeded) Aug 4 00:14:08 ns1 postfix/local[21103]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=0.42, delays=0.09/0/0/0.33, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:14:08 ns1 postfix/local[21103]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=0.47, delays=0.09/0/0/0.38, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:14:08 ns1 postfix/local[21103]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=0.5, delays=0.09/0/0/0.41, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:14:09 ns1 postfix/local[21103]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=0.58, delays=0.09/0/0/0.49, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:14:09 ns1 postfix/local[21103]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=0.65, delays=0.09/0/0/0.56, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:14:09 ns1 postfix/local[21103]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=0.72, delays=0.09/0/0/0.63, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:20:31 ns1 postfix/qmgr[665]: [ID 197553 mail.info] 775993B4F5: from=r...@example.com, size=5316, nrcpt=1 (queue active) Aug 4 00:20:34 ns1 postfix/local[22951]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=386, delays=383/3.1/0/0.02, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:20:34 ns1 postfix/local[22951]: [ID 197553 mail.info] 775993B4F5: to=useroverqu...@example.com, orig_to=syslog-...@example.com, relay=local, delay=386, delays=383/3.1/0/0.04, dsn=4.2.2, status=deferred (maildir delivery failed: error writing message: Disc quota exceeded) Aug 4 00:20:34 ns1 postfix/local[22951]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=386, delays=383/3.1/0/0.06, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:20:34 ns1 postfix/local[22951]: [ID 197553 mail.info] 775993B4F5: to=us...@example.com, orig_to=syslog-...@example.com, relay=local, delay=386, delays=383/3.1/0/0.07, dsn=2.0.0, status=sent (delivered to maildir) Aug 4 00:20:34 ns1 postfix/local[22951]:
Re: Delivery failure for one recipient results in re-delivery for all
* Karl-Johan Karlsson creideiki+postfix-us...@ferretporn.se: I'm having a problem with Postfix 2.4.6, built from source on Solaris 10. Locally delivered mail is placed in maildirs on an NFS-imported disk. The NFS server uses file system quotas. Using alias_maps, mail for root is sent to several users. When one of the expanded recipients goes over quota, Postfix successfully delivers the mail to all other expanded recipients and reports a failed delivery for the user who is over quota. The mail goes into the queue for another delivery attempt a few minutes later. However, what's queued seems to be the original (un-expanded) recipient, so at the next attempt, the alias is expanded again, and the users who are under quota get another copy, while the user that is over quota gets another failure, and the mail is re-queued again. And so it goes, around and around, until someone notices and increases the offending user's quota temporarily, allowing the deliveries to succeed completely and the queue to drain. How can I get Postfix to just re-attempt delivery to the user over quota, not the others? The sample below has a two-step alias expansion (syslog-all - root - user1,...), but the same happens for mail sent directly to root. aliases: syslog-all: root root: user1,useroverquota,user2,user3,user4,user5,user6,user7 add an root-owner: sdoembody alias -- 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
Question regarding Restriction Classes
Hi,
I have a problem with restriction classes that I can't solve. I have a bunch of
restriction classes. In order to simplify this mail I am only using two. One
for SPF checking and the other for Greylisting. Now I would like to have for
each of the restriction classes a bunch of conditions to whitelist by client
ip, sender name or recipient name and that twice. Once on a map per policy
service and one global.
Basically something like that here (simplified example):
---
/etc/postfix/main.cf:
smtpd_restriction_classes =
spf_policy
greylist_policy
spf_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/spf_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/spf_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/spf_recipient_whitelist.cf
check_client_access
pcre:${config_directory}/lookups/pcre/global_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/global_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/global_recipient_whitelist.cf
check_policy_service unix:private/spf-smtpd-policy
greylist_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/greylist_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/greylist_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/greylist_recipient_whitelist.cf
check_client_access
pcre:${config_directory}/lookups/pcre/global_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/global_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/global_recipient_whitelist.cf
check_policy_service inet:127.0.0.1:2501
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
spf_policy
greylist_policy
permit
---
Now my problem is that if I would add an sender/recipient/client ip to one of
the maps for SPF and return OK as action then the Greylisting policy would as
well be overstepped. I don't know what I can add as action to not overstep the
Greylisting policy? I have not tried DUNNO but as far as I understand the DUNNO
would just continue to evaluate the other maps and at the end it would hit the
check_policy_service anyway. Right?
I was thinking in maybe adding another restriction class and branch/jump there
instead of giving an OK. For example:
instead of:
---
/^123\.123\.123\.123$/ OK
---
use this here:
---
/^123\.123\.123\.123$/ dunno_policy
---
and then in main.cf adding dunno_policy to smtpd_restriction_classes and adding
something like that for the dunno_policy:
---
dunno_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/dunno_policy_client.cf
---
and in dunno_policy_client.cf:
---
/./ DUNNO
---
But I am unsure what happens if I branch/jump from one restriction class to
another and the other restriction class has just a DUNNO. Will then the
processing return back to the first restriction class and continue or is the
whole branching/jumping more or less like a flow of processing without
returning back there where it was originally called?
Does anyone know the answer? Is that somewhere described in Postfix? Where?
Or does anyone know a better way in handling such a situation/problem?
// Steve
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: multiple relay hosts in transport - syntax
It would look like Ralf already showed you. But if you are sending to example.org which has the two MX RRs, then there is no need to configure transport maps. If you do use transport maps, the lack of brackets around the nexthop means Postfix will use MX lookups when deciding which nexthop to choose. You CANNOT specify multiple nexthops in the sense you tried to in your original post. Perhaps I left out a detail. There is actually a third mx in dns, which is THIS postfix machine. Although $ host -t mx domain.com domain.com mail is handled by 20 domain.com.bak-mx.smtpblah.com. domain.com mail is handled by 10 domain.com.pri-mx.smtpblah.com. if I do an axfr it is actually: domain.com. 3600IN MX 10 domain.com.pri-mx.smtpblah.com. domain.com. 3600IN MX 20 domain.com.bak-mx.smtpblah.com. domain.com. 3600IN MX 90 POSTFIX.domain.com. So I want to avoid postfix sending mail for domain.com (a valid relay domain, actually our domain) to itself. I am not sure why a straight host lookup did not return the third mx when it is in dns. If this looks strange, it is due to the fact that this MTX's primary role is to relay mail FROM certain hosts which are configured to use this machine as their smtp server without using dns TO anywhere. However, I want to make sure that mail for our domain is also passed on properly back to one of the two mx's I mentioned, without looping back to this postfix. I hope that's clear...
Re: Question about address verification in MX2 when primary MX is down...
Mikael Bak wrote: Santiago Romero wrote: Really, reject_unverified_recipient feature is very nice, but rejecting all mail when primary MX doesn't answers breaks it for us :( Any idea? :? Hi, Quoting the documentation[1]: The unverified_recipient_defer_code parameter (default 450) specifies the numerical Postfix SMTP server reply code when a recipient address probe fails with some temporary error. Some sites insist on changing this into 250. NOTE: This change turns MX servers into backscatter sources when the load is high. So you are not rejecting any email if the MX is down. You are just delaying reject or accept until the MX is asked if there is such user or not. We're very happy with this over here. No, you are not delaying reject. You are bouncing and possibly BackSattering because you really don't know if the recipient is valid. Many, many envelope recipients are forged these days. So you end up bouncing to the wrong place and sending spam to a 3rd party. A good MTA in the world will hold a 450 for 3 to 5 days and keep retrying. If it doesn't retry, it's usually a bot and bad for your health.
Re: Question about address verification in MX2 when primary MX is down...
Brian Evans - Postfix List wrote: Mikael Bak wrote: Santiago Romero wrote: Really, reject_unverified_recipient feature is very nice, but rejecting all mail when primary MX doesn't answers breaks it for us :( Any idea? :? Hi, Quoting the documentation[1]: The unverified_recipient_defer_code parameter (default 450) specifies the numerical Postfix SMTP server reply code when a recipient address probe fails with some temporary error. Some sites insist on changing this into 250. NOTE: This change turns MX servers into backscatter sources when the load is high. So you are not rejecting any email if the MX is down. You are just delaying reject or accept until the MX is asked if there is such user or not. We're very happy with this over here. No, you are not delaying reject. You are bouncing and possibly BackSattering because you really don't know if the recipient is valid. Many, many envelope recipients are forged these days. So you end up bouncing to the wrong place and sending spam to a 3rd party. A good MTA in the world will hold a 450 for 3 to 5 days and keep retrying. If it doesn't retry, it's usually a bot and bad for your health. Hi Brian, Well, thank you for sharing this with me. IMO this setup does not bounce as you say, it sends a 450 Address verification in progress. Try later.. When the client tries next time there is either an OK the address exists, or a 550 User does not exist. Maybe I don't understand what you try to say. I just don't see why this would generate bounces or backscatter. Mikael
Re: Delivery failure for one recipient results in re-delivery for all
On Tuesday 04 August 2009, Ralf Hildebrandt wrote: * Karl-Johan Karlsson creideiki+postfix-us...@ferretporn.se: How can I get Postfix to just re-attempt delivery to the user over quota, not the others? aliases: syslog-all: root root: user1,useroverquota,user2,user3,user4,user5,user6,user7 add an root-owner: sdoembody alias Thanks! That (or, rather, owner-root: somebody) gives the result I want. I only wonder... why? I can't find much documentation on the owner--aliases, and none of it manages to explain this behaviour. -- Karl-Johan Karlsson
Re: Delivery failure for one recipient results in re-delivery for all
Thanks! That (or, rather, owner-root: somebody) gives the result I want. I only wonder... why? I can't find much documentation on the owner--aliases, and none of it manages to explain this behaviour. http://www.postfix.org/aliases.5.html In addition, when an alias exists for owner-name, delivery diagnostics are directed to that address, instead of to the originator of the message. This is typically used to direct delivery errors to the maintainer of a mailing list, who is in a better position to deal with mailing list delivery problems than the originator of the undeliv- ered mail. -- 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: Delivery failure for one recipient results in re-delivery for all
On Tuesday 04 August 2009, Ralf Hildebrandt wrote: Thanks! That (or, rather, owner-root: somebody) gives the result I want. I only wonder... why? I can't find much documentation on the owner--aliases, and none of it manages to explain this behaviour. http://www.postfix.org/aliases.5.html In addition, when an alias exists for owner-name, delivery diagnostics are directed to that address, instead of to the originator of the message. This is typically used to direct delivery errors to the maintainer of a mailing list, who is in a better position to deal with mailing list delivery problems than the originator of the undeliv- ered mail. Yes, I've seen that, and it makes no sense to me, since no delivery diagnostic mails are ever produced, neither with nor without the owner-root alias. -- Karl-Johan Karlsson
Re: Delivery failure for one recipient results in re-delivery for all
* Karl-Johan Karlsson creideiki+postfix-us...@ferretporn.se: On Tuesday 04 August 2009, Ralf Hildebrandt wrote: Thanks! That (or, rather, owner-root: somebody) gives the result I want. I only wonder... why? I can't find much documentation on the owner--aliases, and none of it manages to explain this behaviour. http://www.postfix.org/aliases.5.html In addition, when an alias exists for owner-name, delivery diagnostics are directed to that address, instead of to the originator of the message. This is typically used to direct delivery errors to the maintainer of a mailing list, who is in a better position to deal with mailing list delivery problems than the originator of the undeliv- ered mail. Yes, I've seen that, and it makes no sense to me, since no delivery diagnostic mails are ever produced, neither with nor without the owner-root alias. I know that if a owner- alias is present, alias expansion isn't done on every delivery attempt but instead the alias is expanded and the result of that expansion is saved, at least according to this thread: http://archives.neohapsis.com/archives/postfix/2009-06/0396.html I could be terribly wrong, though. Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 FdI #147: Fortran - Makrosprache für ein I/O-Verhinderungssystem (Arno Eigenwillig)
Correct order of parameters in main.cf
All, please forgive this question if it seems to be a silly one I regard most of the posters to this forum as being experts and truly vaule the information found in your responses to questions and threads. I am a consultant trying to provide secure email services to my clients and am looking to ensure that I configure my postfix server in the best interests of email etiquette and security. My question is - based on several postings where people advise that x line should precede y line or be listed after z - with regards to the auth sections and recipient restrictions etc etc... Is there a set order in which these elemts should be listed in main.cf and if so, is that order published or available anywhere ? Thanks and again i apologise for the question if it seems too much of a newbie question John
Re: Question about address verification in MX2 when primary MX is down...
Mikael Bak wrote: Brian Evans - Postfix List wrote: Mikael Bak wrote: Santiago Romero wrote: Really, reject_unverified_recipient feature is very nice, but rejecting all mail when primary MX doesn't answers breaks it for us :( Any idea? :? Hi, Quoting the documentation[1]: The unverified_recipient_defer_code parameter (default 450) specifies the numerical Postfix SMTP server reply code when a recipient address probe fails with some temporary error. Some sites insist on changing this into 250. NOTE: This change turns MX servers into backscatter sources when the load is high. So you are not rejecting any email if the MX is down. You are just delaying reject or accept until the MX is asked if there is such user or not. We're very happy with this over here. No, you are not delaying reject. You are bouncing and possibly BackSattering because you really don't know if the recipient is valid. Many, many envelope recipients are forged these days. So you end up bouncing to the wrong place and sending spam to a 3rd party. A good MTA in the world will hold a 450 for 3 to 5 days and keep retrying. If it doesn't retry, it's usually a bot and bad for your health. Hi Brian, Well, thank you for sharing this with me. IMO this setup does not bounce as you say, it sends a 450 Address verification in progress. Try later.. When the client tries next time there is either an OK the address exists, or a 550 User does not exist. Maybe I don't understand what you try to say. I just don't see why this would generate bounces or backscatter. Mikael I was referring to the change to 250 that was quoted. I inferred that was the advice being given. If this was incorrect, then, yes, it is just fine to use.
Re: Correct order of parameters in main.cf
John King wrote: All, please forgive this question if it seems to be a silly one I regard most of the posters to this forum as being experts and truly vaule the information found in your responses to questions and threads. I am a consultant trying to provide secure email services to my clients and am looking to ensure that I configure my postfix server in the best interests of email etiquette and security. My question is - based on several postings where people advise that x line should precede y line or be listed after z - with regards to the auth sections and recipient restrictions etc etc... Is there a set order in which these elemts should be listed in main.cf and if so, is that order published or available anywhere ? Thanks and again i apologise for the question if it seems too much of a newbie question The defaults are generally sane. Understand that Postfix does not evaluate line order. What matters is order in restrictions. You must find what works for your situation. Postfix is very flexible. The most critical restriction is reject_unauth_destination. Placement of check_recipient_access or check_sender access before this in smtpd_recipient_restrictions *may* lead to an open relay.
Re: Correct order of parameters in main.cf
* Brian Evans - Postfix List grkni...@scent-team.com: Understand that Postfix does not evaluate line order. unless in smtpd_*_restrictions The most critical restriction is reject_unauth_destination. Placement of check_recipient_access or check_sender access before this in smtpd_recipient_restrictions *may* lead to an open relay. Amen! -- 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: Question about address verification in MX2 when primary MX is down...
Brian Evans - Postfix List wrote: Mikael Bak wrote: Brian Evans - Postfix List wrote: Mikael Bak wrote: Santiago Romero wrote: Really, reject_unverified_recipient feature is very nice, but rejecting all mail when primary MX doesn't answers breaks it for us :( Any idea? :? Hi, Quoting the documentation[1]: The unverified_recipient_defer_code parameter (default 450) specifies the numerical Postfix SMTP server reply code when a recipient address probe fails with some temporary error. Some sites insist on changing this into 250. NOTE: This change turns MX servers into backscatter sources when the load is high. So you are not rejecting any email if the MX is down. You are just delaying reject or accept until the MX is asked if there is such user or not. We're very happy with this over here. No, you are not delaying reject. You are bouncing and possibly BackSattering because you really don't know if the recipient is valid. Many, many envelope recipients are forged these days. So you end up bouncing to the wrong place and sending spam to a 3rd party. A good MTA in the world will hold a 450 for 3 to 5 days and keep retrying. If it doesn't retry, it's usually a bot and bad for your health. Hi Brian, Well, thank you for sharing this with me. IMO this setup does not bounce as you say, it sends a 450 Address verification in progress. Try later.. When the client tries next time there is either an OK the address exists, or a 550 User does not exist. Maybe I don't understand what you try to say. I just don't see why this would generate bounces or backscatter. Mikael I was referring to the change to 250 that was quoted. I inferred that was the advice being given. If this was incorrect, then, yes, it is just fine to use. Hi Brian, I knew that we were misunderstanding eachother. :-) So to clarify. We have the unverified_recipient_defer_code parameter set to its default (450). Mikael
Re: Delivery failure for one recipient results in re-delivery for all
On Tuesday 04 August 2009, Stefan Förster wrote: I know that if a owner- alias is present, alias expansion isn't done on every delivery attempt but instead the alias is expanded and the result of that expansion is saved, at least according to this thread: http://archives.neohapsis.com/archives/postfix/2009-06/0396.html URL:http://archives.neohapsis.com/archives/postfix/2009-06/0486.html seems to explain what I'm seeing perfectly. I'd suggest that that information be incorporated into aliases(5) or ADDRESS_REWRITING_README - it seems too big a behaviour change with too bad results to be documented only on the mailing list. -- Karl-Johan Karlsson
Re: Correct order of parameters in main.cf
On Tuesday 04 August 2009 16:08:06 John King wrote: My question is - based on several postings where people advise that x line should precede y line or be listed after z - with regards to the auth sections and recipient restrictions etc etc... Is there a set order in which these elemts should be listed in main.cf and if so, is that order published or available anywhere ? I'm no expert, but I think the answer is no, it depends on policy. Typically you want to accept authenticated users, and trusted hosts, before checking blocklists. But as more and more spammer use stolen credentials it maybe that some folk will refuse known bots before considering authentication credentials, so they will perhaps put the CBL or XBL (lists of known spambots) before anything else. Similarly some spam checks are far cheaper than others, it makes sense to do the most cost effective spam tests first (which typically means anything that avoids disk I/O (especially writing) before tests that write to disk. I have on my personal server for recipients: permit_sasl_authenticated, permit_mynetworks, blocklists policy servers reject_unauth_destination Which I think is pretty typical, but there is proabbly no right way. Ralf Hildrebrandt has his own configuration and some example on his site, which are useful for those of us whose brains aren't as fit as they once were. http://www.arschkrebs.de/postfix/
RE: New Antispam settings
Hello, Thank you for your suggestions. I will make the changes. Any other suggestions welcome. Thanks. Dave. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Magnus Bäck Sent: Tuesday, August 04, 2009 9:39 AM To: postfix-users@postfix.org Subject: Re: New Antispam settings On Tuesday, August 04, 2009 at 10:17 CEST, Dave dave.meh...@gmail.com wrote: [...] disable_vrfy_command = yes Doesn't hurt, but I hope you realize that it doesn't really buy you anything either since anyone can determine valid recipients via the RCPT TO response. [...] smtpd_banner = $myhostname No, don't change this. If you want to hide that it's Postfix answering the door (futile since an SMTP server can easily be identified as Postfix anyway), just remove that part. Keep ESMTP. A general comment is that you restate the default value of several parameters. [...] -- Magnus Bäck mag...@dsek.lth.se
Re: Correct order of parameters in main.cf
Thanks very much Simon, Ralf and Brian Much appreciated and i shall continue to read everyone's postings to stay up to date on the requirements John - Original Message From: Simon Waters sim...@zynet.net To: postfix-users@postfix.org Sent: Tuesday, August 4, 2009 10:30:37 AM Subject: Re: Correct order of parameters in main.cf On Tuesday 04 August 2009 16:08:06 John King wrote: My question is - based on several postings where people advise that x line should precede y line or be listed after z - with regards to the auth sections and recipient restrictions etc etc... Is there a set order in which these elemts should be listed in main.cf and if so, is that order published or available anywhere ? I'm no expert, but I think the answer is no, it depends on policy. Typically you want to accept authenticated users, and trusted hosts, before checking blocklists. But as more and more spammer use stolen credentials it maybe that some folk will refuse known bots before considering authentication credentials, so they will perhaps put the CBL or XBL (lists of known spambots) before anything else. Similarly some spam checks are far cheaper than others, it makes sense to do the most cost effective spam tests first (which typically means anything that avoids disk I/O (especially writing) before tests that write to disk. I have on my personal server for recipients: permit_sasl_authenticated, permit_mynetworks, blocklists policy servers reject_unauth_destination Which I think is pretty typical, but there is proabbly no right way. Ralf Hildrebrandt has his own configuration and some example on his site, which are useful for those of us whose brains aren't as fit as they once were. http://www.arschkrebs.de/postfix/
Re: Black magic rejecting header Subjects
Lukas, On 8/4/2009 1:02 AM, Lukas Ruf wrote: On Monday 03 August 2009 15:34:59 Lukas Ruf wrote: I cannot understand why Postfix/cleanup rejects particular Subject lines, since I have been searching for the respective regexps but haven't found what I've been looking for. My question is simple: why are subject lines rejected that I cannot find definitions for? Probably because they match expressions in your undisclosed [!!] file of header_checks(5). Please find attached the header_checks file currently in use: When I comment the line in main.cf header_checks = pcre:/etc/postfix/header_checks.pcre everything works for me as expected. Thus, I strongly assume there must be a bug somewhere in the definitions Thanks for your support! wbr, Lukas This header_checks file is out of control. It rejects many perfectly reasonable Subjects: $ postmap -q 'Subject: I need a hand please' \ pcre:/tmp/map REJECT $ postmap -q 'Subject: for election news' \ pcre:/tmp/map REJECT Your question re: matching 'ferte e': $ postmap -q 'Subject: ferte e' pcre:/tmp/map REJECT --- matched HERE whiche come from (the modified): /^Subject: .*F.R.E.E/ REJECT --- matched HERE Spend some time learning about REs. And consider instead of this monstrosity header_checks file a content filter or other more sufficient means. If you must use header_check rules, include unique identifiers at the end of your REJECTs so that you can find which ones hit. See example with HERE above. See: http://www.postfix.org/header_checks.5.html http://www.postfix.org/access.5.html http://www.postfix.org/CONTENT_INSPECTION_README.html
Re: Correct order of parameters in main.cf
Simon Waters wrote: I have on my personal server for recipients: permit_sasl_authenticated, permit_mynetworks, blocklists policy servers reject_unauth_destination Which I think is pretty typical, but there is proabbly no right way. Some would consider this less than optimal for checking rbls and your policy service before determining if you even are responsible for the mail. IMO, the optimal order above would be: permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination blocklists policy servers
Re: Postfix SMTP server: errors from 6.mail-out.ovh.net[91.121.25.210]
I just changed the password. sorry i'am r13151.ovh.net On Tue, 4 Aug 2009 18:06:42 +0200 (CEST), mailer-dae...@r13151.ovh.net (Mail Delivery System) wrote: Transcript of session follows. Out: 220 r13151.ovh.net ESMTP Postfix (2.5.1) In: HELO 6.mail-out.ovh.net Out: 250 r13151.ovh.net In: MAIL FROM:rps-return-25004-fakessh=fakessh...@ml.ovh.net Out: 250 2.1.0 Ok In: RCPT TO:fake...@fakessh.eu Out: 451 4.3.5 Server configuration error In: QUIT Out: 221 2.0.0 Bye
Re: Black magic rejecting header Subjects
Dear MrC MrC lists-post...@cappella.us [2009-08-04 17:53]: On 8/4/2009 1:02 AM, Lukas Ruf wrote: On Monday 03 August 2009 15:34:59 Lukas Ruf wrote: I cannot understand why Postfix/cleanup rejects particular Subject lines, since I have been searching for the respective regexps but haven't found what I've been looking for. My question is simple: why are subject lines rejected that I cannot find definitions for? Probably because they match expressions in your undisclosed [!!] file of header_checks(5). Please find attached the header_checks file currently in use: This header_checks file is out of control. It rejects many perfectly reasonable Subjects: Thank you very much for your reply! It dates back to somewhen in 2003 Spend some time learning about REs. And consider instead of this monstrosity header_checks file a content filter or other more sufficient means. If you must use header_check rules, include unique identifiers at the end of your REJECTs so that you can find which ones hit. See example with HERE above. See: http://www.postfix.org/header_checks.5.html http://www.postfix.org/access.5.html http://www.postfix.org/CONTENT_INSPECTION_README.html Thank you very much for the recommendation. I definitely will! wbr, Lukas -- Lukas Ruf http://www.lpr.ch | Ad Personam Consecom http://www.consecom.com | Ad Laborem
receipient_delimiter change
Hi, We currently use the default recipient_delimiter of '+', but I've been receiving requests to change it to a '.' as some sites will not sanity-check properly with the plus, but will do it with the period. Is there an easy way to migrate from one to the other such as enabling both as a delimiter, or will I just have to go have all the users change their registered email addresses on the various sites they've registered their '+' emails on? hose
Re: Postfix SMTP server: errors from 6.mail-out.ovh.net[91.121.25.210]
I just changed the password. sorry I'm r13151.ovh.net On Tue, 4 Aug 2009 18:16:52 +0200 (CEST), mailer-dae...@r13151.ovh.net (Mail Delivery System) wrote: Transcript of session follows. Out: 220 r13151.ovh.net ESMTP Postfix (2.5.1) In: HELO 6.mail-out.ovh.net Out: 250 r13151.ovh.net In: MAIL FROM:rps-return-25008-fakessh=fakessh...@ml.ovh.net Out: 250 2.1.0 Ok In: RCPT TO:fake...@fakessh.eu Out: 451 4.3.5 Server configuration error In: QUIT Out: 221 2.0.0 Bye
Re: receipient_delimiter change
On Tuesday 04 August 2009 17:19:10 Hose wrote: We currently use the default recipient_delimiter of '+', but I've been receiving requests to change it to a '.' as some sites will not sanity-check properly with the plus, but will do it with the period. Is there an easy way to migrate from one to the other such as enabling both as a delimiter, or will I just have to go have all the users change their registered email addresses on the various sites they've registered their '+' emails on? Did you read this slightly related but different thread? http://www.irbs.net/internet/postfix/0110/0554.html Discusses how to rewrite and when and why it might be a bad idea. Sometimes this is one of those settings it was best to get right first time, but it depends what addresses you have in use and how extensive the use of it is. Alternatively put on your BoFH hat, and explain that + is allowed in email addresses in the RFCs and change your email address to + till they get the hint. I'm told email addresses consisting only of allowed symbols rather than alphanumerics get a lot less spam, but I've never tried it. People with apostrophes in their name will salute your support for the RFCs.
Re: multiple relay hosts in transport - syntax
I apologize if this is a dupe post, but my client was not showing my previous post properly... Perhaps I left out a detail. There is actually a third mx in dns, which is THIS postfix machine. Although $ host -t mx domain.com domain.com mail is handled by 20 domain.com.bak-mx.smtpblah.com. domain.com mail is handled by 10 domain.com.pri-mx.smtpblah.com. if I do an axfr it is actually: domain.com. 3600IN MX 10 domain.com.pri-mx.smtpblah.com. domain.com. 3600IN MX 20 domain.com.bak-mx.smtpblah.com. domain.com. 3600IN MX 90 POSTFIX.domain.com. So I want to avoid postfix sending mail for domain.com (a valid relay domain, actually our domain) to itself. I am not sure why a straight host lookup did not return the third mx when it is in dns. (thoughts?) If this looks strange, it is due to the fact that this MTX's primary role is to relay mail FROM certain hosts which are configured to use this machine as their smtp server without using dns TO anywhere. However, I want to make sure that mail for our domain (from ANYWHERE) is also passed on properly back to one of the two mx's I mentioned, without looping back to this postfix. I hope that's clear... alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 default_destination_recipient_limit = 20 default_process_limit = 10 disable_vrfy_command = yes html_directory = no local_recipient_maps = mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydomain = escapewire.com myhostname = host.domain.com mynetworks = 127.0.0.0/8, /etc/postfix/relay-ip newaliases_path = /usr/bin/newaliases.postfix readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES relay_domains = escapewire.com relay_recipient_maps = hash:/etc/postfix/relay_recipients relay_transport = smtp sample_directory = /usr/share/doc/postfix-2.2.10/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_connect_timeout = 30s smtp_helo_timeout = 60s smtpd_banner = $myhostname ESMTP $mail_name smtpd_client_connection_count_limit = 50 smtpd_client_connection_rate_limit = 50 smtpd_client_event_limit_exceptions = 127.0.0.0/8 smtpd_client_message_rate_limit = 50 smtpd_client_recipient_rate_limit = 50 smtpd_client_restrictions = smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unlisted_sender, reject_invalid_hostname, reject_unknown_sender_domain, permit_mynetworks, reject_unauth_destination, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_access, check_recipient_access hash:/etc/postfix/roleaccount, reject_rhsbl_sender dsn.rfc-ignorant.org permit smtpd_sender_restrictions = unknown_local_recipient_reject_code = 550
Re: multiple relay hosts in transport - syntax
Andrew Long wrote: I apologize if this is a dupe post, but my client was not showing my previous post properly... Perhaps I left out a detail. There is actually a third mx in dns, which is THIS postfix machine. Although [gmail eats your own posts from the list as a duplicate, so you won't see the list posting] postfix is clever enough that it won't send mail to itself. However, if this box is the primary MX, it won't send mail to a secondary either; you need a transport map in this case. Solve that problem either with split-horizon DNS, or use a some .local domain with MX records pointing to the other hosts. -- Noel Jones
Am I an open relay?
Hello, I'm adjusting my postfix configuration to try to cut down on the spam i'm getting. I have noticed an event in my maillog that has me concerned that i'm now inadvertently an open relay. If this is so i'd like to fix it. Here's the error: Aug 4 11:18:12 hostname postfix/smtp[22025]: 48A91150900A8: to=wallopingsfc...@autourdupiano.com, relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31, delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok) Aug 4 11:18:12 Hostname postfix/qmgr[21957]: 48A91150900A8: removed And a postconf -n: address_verify_map = btree:/var/spool/postfix/verified_senders alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases biff = no broken_sasl_auth_clients = yes canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_checks home_mailbox = Maildir/ html_directory = no inet_interfaces = 127.0.0.1, External IP invalid_hostname_reject_code = 554 local_recipient_maps = proxy:unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_size_limit = 104857600 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 20971520 mime_header_checks = pcre:/etc/postfix/mime_header_checks multi_recipient_bounce_reject_code = 554 mydomain = example.com myhostname = mail.example.com mynetworks = 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_fqdn_reject_code = 554 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES recipient_delimiter = + relay_domains_reject_code = 554 sample_directory = /usr/share/doc/postfix-2.3.3/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop show_user_unknown_table_name = no smtp_helo_timeout = 60s smtpd_banner = $myhostname ESMTP smtpd_data_restrictions = reject_unauth_pipelining smtpd_helo_required = yes smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unverified_sender reject_unverified_recipient reject_multi_recipient_bounce, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,check_helo_access hash:/etc/postfix/helo_checks, check_helo_access pcre:/etc/postfix/helo_checks.pcre check_sender_mx_access cidr:/etc/postfix/bogus_mx reject_rbl_client zen.spamhaus.org, reject_rbl_client black.uribl.com, reject_rbl_client combined.rbl.msrbl.net, reject_rhsbl_sender dsn.rfc-ignorant.org smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_CAfile = /etc/postfix/ssl/ca-cert.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/ssl/smtp.crt smtpd_tls_key_file = /etc/postfix/ssl/smtp.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_cache smtpd_tls_session_cache_timeout = 3600s strict_rfc821_envelopes = yes tls_random_source = dev:/dev/urandom unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 unknown_relay_recipient_reject_code = 554 unknown_virtual_alias_reject_code = 554 unknown_virtual_mailbox_reject_code = 554 unverified_recipient_reject_code = 554 unverified_sender_reject_code = 554 virtual_alias_maps = hash:/etc/postfix/virtual_alias virtual_gid_maps = static:5000 virtual_mailbox_base = /home/vmail virtual_mailbox_domains = /etc/postfix/vhosts virtual_mailbox_maps = hash:/etc/postfix/vmaps virtual_minimum_uid = 1000 virtual_uid_maps = static:5000 Thanks. Dave.
Re: Postfix HELO FQDN requirement
Robin Smidsrød wrote: Mikael Bak wrote: Robin Smidsrød wrote: I've had at least one client leave because he absolutely needs to have every email, because every single email he receives could be really important. So dealing with spam is something he just has to do. On the other hand I have users that don't really care one way or the other. I just want to be able to let the user make that choice. And rejecting email based on (possibly forged) helo is a system-wide policy, not a user-specific policy. Is it possible to make this a user-policy? It is possible to make rules user and/or domain dependant with carefully built restriction classes. If you haven't read this already, please do: http://www.postfix.org/RESTRICTION_CLASS_README.html Thanks for the link. It indeed explains how to make rules user-definable. Of course, to enable use of check_recipient_access in smtpd_helo_restrictions, smtpd_delay_reject must obviously be set to Yes (the default). -- Robin You can also use a check_recipient_access table that returns the restrictions you want applied to that particular recipient domain or user. As long as you're not doing table lookups, you don't need smtpd_restriction_classes. smtpd_recipient_restrictions = ... check_recipient_access hash:/etc/postfix/restrictions ... # /etc/postfix/restrictions u...@example.com reject_non_fqdn_hostname, reject_rbl_clie... example.com permit_auth_destination ... -- Noel Jones
Re: Am I an open relay?
* Dave dave.meh...@gmail.com: Hello, I'm adjusting my postfix configuration to try to cut down on the spam i'm getting. I have noticed an event in my maillog that has me concerned that i'm now inadvertently an open relay. If this is so i'd like to fix it. Here's the error: Aug 4 11:18:12 hostname postfix/smtp[22025]: 48A91150900A8: to=wallopingsfc...@autourdupiano.com, relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31, delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok) Aug 4 11:18:12 Hostname postfix/qmgr[21957]: 48A91150900A8: removed And the other entries for 48A91150900A8 ? Not an open relay, unless you played clever tricks in master.cf -- 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: Am I an open relay?
* Dave dave.meh...@gmail.com: Hello, I'm adjusting my postfix configuration to try to cut down on the spam i'm getting. I have noticed an event in my maillog that has me concerned that i'm now inadvertently an open relay. If this is so i'd like to fix it. Here's the error: Aug 4 11:18:12 hostname postfix/smtp[22025]: 48A91150900A8: to=wallopingsfc...@autourdupiano.com, relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31, delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok) Aug 4 11:18:12 Hostname postfix/qmgr[21957]: 48A91150900A8: removed That's sender address verification -- 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: Am I an open relay?
Dave wrote: Hello, I'm adjusting my postfix configuration to try to cut down on the spam i'm getting. I have noticed an event in my maillog that has me concerned that i'm now inadvertently an open relay. If this is so i'd like to fix it. Here's the error: Aug 4 11:18:12 hostname postfix/smtp[22025]: 48A91150900A8: to=wallopingsfc...@autourdupiano.com, relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31, delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok) Aug 4 11:18:12 Hostname postfix/qmgr[21957]: 48A91150900A8: removed This is a sender verification probe from your reject_unverified_sender restriction. Notice the deliverable tag. As a general rule it's a bad idea to verify all senders since some mail admins see this as abuse and will blacklist you. Best use with caution. -- Noel Jones
Re: Black magic rejecting header Subjects
Lukas Ruf wrote: # This is the access filter file for mail.securitysage.com, published by SecuritySage # This filter is the work of Jeffrey Posluns j...@posluns.com These header checks are no longer maintained. I strongly suggest you *remove them all* unless you fully understand what they do. and besides, I'll bet they don't catch much spam that won't be rejected by zen.spamhaus.org. -- Noel Jones
RE: Am I an open relay?
Hi, Thanks for your reply. For reject_unverified_sender what would be a better way of dealing with it? Thanks. Dave. -Original Message- From: Noel Jones [mailto:njo...@megan.vbhcs.org] Sent: Tuesday, August 04, 2009 1:02 PM To: dave.meh...@gmail.com; postfix-users@postfix.org Subject: Re: Am I an open relay? Dave wrote: Hello, I'm adjusting my postfix configuration to try to cut down on the spam i'm getting. I have noticed an event in my maillog that has me concerned that i'm now inadvertently an open relay. If this is so i'd like to fix it. Here's the error: Aug 4 11:18:12 hostname postfix/smtp[22025]: 48A91150900A8: to=wallopingsfc...@autourdupiano.com, relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31, delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok) Aug 4 11:18:12 Hostname postfix/qmgr[21957]: 48A91150900A8: removed This is a sender verification probe from your reject_unverified_sender restriction. Notice the deliverable tag. As a general rule it's a bad idea to verify all senders since some mail admins see this as abuse and will blacklist you. Best use with caution. -- Noel Jones
RE: Am I an open relay?
Hello, Thanks for your reply. I have not added any services to master.cf. Thanks a lot. Dave. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Ralf Hildebrandt Sent: Tuesday, August 04, 2009 12:59 PM To: postfix-users@postfix.org Subject: Re: Am I an open relay? * Dave dave.meh...@gmail.com: Hello, I'm adjusting my postfix configuration to try to cut down on the spam i'm getting. I have noticed an event in my maillog that has me concerned that i'm now inadvertently an open relay. If this is so i'd like to fix it. Here's the error: Aug 4 11:18:12 hostname postfix/smtp[22025]: 48A91150900A8: to=wallopingsfc...@autourdupiano.com, relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31, delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok) Aug 4 11:18:12 Hostname postfix/qmgr[21957]: 48A91150900A8: removed And the other entries for 48A91150900A8 ? Not an open relay, unless you played clever tricks in master.cf -- 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: Reverse DNS requirement
On Tue, 04 Aug 2009 11:42:03 +0200 Thomas Gelf tho...@gelf.net wrote: e) we are a really small ISP, but the largest one in our region. Two years ago we decided to be less permissive - and we had to dedicate ressources to teach people what they are doing wrong. The result has been, that other providers in our region are now doing the very same thing, and if someone complains they take us as a reference They are also doing so, many ISPs do so - fix your system, don't blame us. It's all just a matter of time - and as more and more very large Mail providers are enforcing correct behaviour it is becoming much easier to set up such restrictions. There is always the AOL Rule. I find it useful to ask, are you having delivery problems to AOL, too? They always reply, oh, yeah, is that related? In most cases they fix it. In the few they don't, well, they still can't mail AOL either, they just don't understand how to fix their problems. [quote] AOL's mail servers will reject connections from any IP address that does not have reverse DNS (a PTR record). All e-mail servers connecting to AOL's mail servers must have valid and meaningful (not dynamic-looking) reverse DNS records. For example: * Meaningful RDNS: mail.domain.com * Generic RDNS: 1.2.3.4.domain.isp.com [/quote] http://postmaster.info.aol.com/guidelines/standards.html I don't think it's a sin to reject mail lacking reverse DNS: the 900 pound gorrilla of AOL does. (Not that I agree, by any means, with all their policies.. but wow, and you can't send mail to the one of the largest providers in the world either... looks like YOU have a problem helps justify being more strict. (Hotmail and Gmail have similar rules, I just don't know where they spell them out.)
Re: Reverse DNS requirement
brian moore wrote: There is always the AOL Rule. Yeah, we are sometimes also using AOL as an example, even if where I live nearly nobody is using it... (Hotmail and Gmail have similar rules, I just don't know where they spell them out.) Hotmail: http://postmaster.msn.com/Guidelines.aspx Gmail: no idea, found nothing but a dummy-user-faq
Re: Question regarding Restriction Classes
On Tuesday 04 August 2009 07:48:12 Steve wrote:
I have a problem with restriction classes that I can't solve. I have a
bunch of restriction classes. In order to simplify this mail I am only
using two. One for SPF checking and the other for Greylisting. Now I would
like to have for each of the restriction classes a bunch of conditions to
whitelist by client ip, sender name or recipient name and that twice. Once
on a map per policy service and one global.
Basically something like that here (simplified example):
---
/etc/postfix/main.cf:
smtpd_restriction_classes =
spf_policy
greylist_policy
spf_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/spf_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/spf_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/spf_recipient_whitelist.cf
check_client_access
pcre:${config_directory}/lookups/pcre/global_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/global_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/global_recipient_whitelist.cf
check_policy_service unix:private/spf-smtpd-policy
greylist_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/greylist_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/greylist_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/greylist_recipient_whitelist.cf
check_client_access
pcre:${config_directory}/lookups/pcre/global_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/global_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/global_recipient_whitelist.cf
check_policy_service inet:127.0.0.1:2501
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
spf_policy
greylist_policy
permit
---
Now my problem is that if I would add an sender/recipient/client ip to one
of the maps for SPF and return OK as action then the Greylisting policy
would as well be overstepped. I don't know what I can add as action to not
overstep the Greylisting policy? I have not tried DUNNO but as far as I
understand the DUNNO would just continue to evaluate the other maps and at
the end it would hit the check_policy_service anyway. Right?
I was thinking in maybe adding another restriction class and branch/jump
there instead of giving an OK. For example:
Right ...
instead of:
---
/^123\.123\.123\.123$/ OK
---
use this here:
---
/^123\.123\.123\.123$/ dunno_policy
---
and then in main.cf adding dunno_policy to smtpd_restriction_classes and
adding something like that for the dunno_policy: ---
dunno_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/dunno_policy_client.cf ---
and in dunno_policy_client.cf:
---
/./ DUNNO
---
But I don't think this is it. What you want to do is make subclasses
that continue on into your restrictions.
But I am unsure what happens if I branch/jump from one restriction class to
another and the other restriction class has just a DUNNO. Will then the
processing return back to the first restriction class and continue or is
the whole branching/jumping more or less like a flow of processing without
returning back there where it was originally called?
DUNNO is going to exit only that one restriction, and continue with the
next specified restriction. It doesn't matter that you came in via a
restriction class; DUNNO is not going to exit the class.
restriction_classes = class_relay_ok, class_helo, class_grey, class_rbl
class_relay_ok = permit_mynetworks, permit_sasl_authenticated
class_helo = check_helo_access pcre:$config_directory/helo,
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname
class_grey = check_policy_service ...
class_rbl = reject_rbl_client ...
smtpd_recipient_restrictions = class_relay_ok, check_recipient_access
hash:$config_directory/rcpt_restrict, reject_unauth_destination
Add more classes and granularity as desired. Then in the rcpt_restrict
map, call the classes you want, per recipient or per domain.
g...@example.comclass_helo, class_grey, class_rbl
nog...@example.com class_helo, class_rbl
wants...@example.comreject_unauth_destination
Does anyone know the answer? Is that somewhere described in Postfix? Where?
Or does anyone know a better way in handling such a situation/problem?
Not sure. I do know that you will need lots of caffeine and analgesics
as you develop and debug this. And then you'll never want to look at it
again! (Don't ask how I know this!)
--
Offlist mail to this address is discarded unless
/dev/rob0 or not-spam is in Subject: header
Postgrey and Postfix
I raise this question here because it appears the basic postgrey daemon is running I have a FReebsd 7.0 server with Postfix, amavisd-new, Dovecot to which i added Postgrey I have postgrey runnng as a ps aux grep | postfix shows postgrey 653 0.0 2.4 14384 12052 ?? Is1:53PM 0:00.04 /usr/ local/sbin/postgrey --pidfile=/var/run/postgrey.pid --inet=10023 -d -- user=postgrey --group=postgrey --dbdir=/var/db/postgrey (perl5.8.9) There is no indication in the syslog maillog of any postgrey activity so I am presuming that i have messed up the install or configuration.. postconf -n shows command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix delay_warning_time = 4h disable_vrfy_command = yes header_checks = regexp:/usr/local/etc/postfix/header_checks home_mailbox = Maildir/ html_directory = no mail_owner = postfix mail_spool_directory = /var/mail/vmail mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man maps_rbl_domains = bl.spamcop.net mydestination = localhost.$mydomain, localhost myhostname = compnay.com mynetworks = 127.0.0.0/8, xxx.. myorigin = $myhostname newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no receive_override_options = no_address_mappings relay_recipient_maps = hash:/usr/local/etc/postfix/relay_recipients sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_tls_note_starttls_offer = yes smtpd_banner = Hi This is No One smtpd_helo_required = yes smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,check_helo_access hash:/usr/local/etc/postfix/ helo_access,reject_invalid_hostname,reject_unknown_hostname smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains,reject_rbl_client zen.spamhaus.org bl,reject_rbl_client bl.spamcop.net,reject_rbl_client cbl.abuseat.org,reject_rbl_client safe.dnsbl.sorbs.net,check_policy_service inet:127.0.0.1 smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostnamebroken_sasl_auth_clients = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_sender_restrictions = permit_sasl_authenticated, reject_rhsbl_sender dsn.rfc-ignorant.org, reject_rbl_client bl.spamcop.net smtpd_tls_CAfile = /etc/mail/certs/root.crt smtpd_tls_cert_file = /etc/mail/certs/server.pem smtpd_tls_key_file = /etc/mail/certs/server.key smtpd_tls_loglevel = 3 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/usr/local/etc/postfix/virtual virtual_gid_maps = static:1000 virtual_mailbox_base = /var/mail/vmail virtual_mailbox_domains = /usr/local/etc/postfix/virtual_domains virtual_mailbox_maps = hash:/usr/local/etc/postfix/virtual_mailbox virtual_minimum_uid = 100 virtual_uid_maps = static:1003 Can anyone provide me any ideas ?? I have also rasied the question on the postgrey mailing list Jason
Re: Postgrey and Postfix
Quoting Jason Hirsh hir...@att.net: I raise this question here because it appears the basic postgrey daemon is running I have a FReebsd 7.0 server with Postfix, amavisd-new, Dovecot to which i added Postgrey I have postgrey runnng as a ps aux grep | postfix shows postgrey 653 0.0 2.4 14384 12052 ?? Is1:53PM 0:00.04 /usr/local/sbin/postgrey --pidfile=/var/run/postgrey.pid --inet=10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey (perl5.8.9) Your running postgrey on port 10023. Is it assumed to run on the IP 127.0.0.1 if not specified? Also, note below: There is no indication in the syslog maillog of any postgrey activity so I am presuming that i have messed up the install or configuration.. postconf -n shows command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix delay_warning_time = 4h disable_vrfy_command = yes header_checks = regexp:/usr/local/etc/postfix/header_checks home_mailbox = Maildir/ html_directory = no mail_owner = postfix mail_spool_directory = /var/mail/vmail mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man maps_rbl_domains = bl.spamcop.net mydestination = localhost.$mydomain, localhost myhostname = compnay.com mynetworks = 127.0.0.0/8, xxx.. myorigin = $myhostname newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no receive_override_options = no_address_mappings relay_recipient_maps = hash:/usr/local/etc/postfix/relay_recipients sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_tls_note_starttls_offer = yes smtpd_banner = Hi This is No One smtpd_helo_required = yes smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,check_helo_access hash:/usr/local/etc/postfix/helo_access,reject_invalid_hostname,reject_unknown_hostname smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains,reject_rbl_client zen.spamhaus.org bl,reject_rbl_client bl.spamcop.net,reject_rbl_client cbl.abuseat.org,reject_rbl_client safe.dnsbl.sorbs.net,check_policy_service inet:127.0.0.1 Above, you are running postgrey on port 10023 yet you haven't told check_policy_service. I.e. check_policy_service inet:127.0.0.1:10023 smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostnamebroken_sasl_auth_clients = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_sender_restrictions = permit_sasl_authenticated, reject_rhsbl_sender dsn.rfc-ignorant.org, reject_rbl_client bl.spamcop.net smtpd_tls_CAfile = /etc/mail/certs/root.crt smtpd_tls_cert_file = /etc/mail/certs/server.pem smtpd_tls_key_file = /etc/mail/certs/server.key smtpd_tls_loglevel = 3 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/usr/local/etc/postfix/virtual virtual_gid_maps = static:1000 virtual_mailbox_base = /var/mail/vmail virtual_mailbox_domains = /usr/local/etc/postfix/virtual_domains virtual_mailbox_maps = hash:/usr/local/etc/postfix/virtual_mailbox virtual_minimum_uid = 100 virtual_uid_maps = static:1003 Can anyone provide me any ideas ?? I have also rasied the question on the postgrey mailing list Jason
Re: Question regarding Restriction Classes
Original-Nachricht
Datum: Tue, 4 Aug 2009 13:01:12 -0500
Von: /dev/rob0 r...@gmx.co.uk
An: postfix-users@postfix.org
Betreff: Re: Question regarding Restriction Classes
On Tuesday 04 August 2009 07:48:12 Steve wrote:
I have a problem with restriction classes that I can't solve. I have a
bunch of restriction classes. In order to simplify this mail I am only
using two. One for SPF checking and the other for Greylisting. Now I
would
like to have for each of the restriction classes a bunch of conditions
to
whitelist by client ip, sender name or recipient name and that twice.
Once
on a map per policy service and one global.
Basically something like that here (simplified example):
---
/etc/postfix/main.cf:
smtpd_restriction_classes =
spf_policy
greylist_policy
spf_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/spf_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/spf_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/spf_recipient_whitelist.cf
check_client_access
pcre:${config_directory}/lookups/pcre/global_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/global_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/global_recipient_whitelist.cf
check_policy_service unix:private/spf-smtpd-policy
greylist_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/greylist_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/greylist_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/greylist_recipient_whitelist.cf
check_client_access
pcre:${config_directory}/lookups/pcre/global_client_whitelist.cf
check_sender_access
pcre:${config_directory}/lookups/pcre/global_sender_whitelist.cf
check_recipient_access
pcre:${config_directory}/lookups/pcre/global_recipient_whitelist.cf
check_policy_service inet:127.0.0.1:2501
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
spf_policy
greylist_policy
permit
---
Now my problem is that if I would add an sender/recipient/client ip to
one
of the maps for SPF and return OK as action then the Greylisting policy
would as well be overstepped. I don't know what I can add as action to
not
overstep the Greylisting policy? I have not tried DUNNO but as far as I
understand the DUNNO would just continue to evaluate the other maps and
at
the end it would hit the check_policy_service anyway. Right?
I was thinking in maybe adding another restriction class and branch/jump
there instead of giving an OK. For example:
Right ...
instead of:
---
/^123\.123\.123\.123$/ OK
---
use this here:
---
/^123\.123\.123\.123$/ dunno_policy
---
and then in main.cf adding dunno_policy to smtpd_restriction_classes and
adding something like that for the dunno_policy: ---
dunno_policy =
check_client_access
pcre:${config_directory}/lookups/pcre/dunno_policy_client.cf ---
and in dunno_policy_client.cf:
---
/./ DUNNO
---
But I don't think this is it. What you want to do is make subclasses
that continue on into your restrictions.
This statement I don't understand. Allow me to rephrase what I have understood
from the above paragraph:
Restrictions are mubmle_restrictions (aka
(smtpd_client|smtpd_helo|smtpd_sender|smtpd_recipient|smtpd_data|smtpd_end_of_data|smtpd_etrn)_restrictions)
What are subclasses? I don't know what that is?
But I am unsure what happens if I branch/jump from one restriction class
to
another and the other restriction class has just a DUNNO. Will then the
processing return back to the first restriction class and continue or is
the whole branching/jumping more or less like a flow of processing
without
returning back there where it was originally called?
DUNNO is going to exit only that one restriction, and continue with the
next specified restriction. It doesn't matter that you came in via a
restriction class; DUNNO is not going to exit the class.
So inside a restriction I can have multiple classes called. If in one of the
classes I do an OK then the whole restriction is exited. Right?
If in one of the classes I do a DUNNO then the execution stays inside the class
and continues. Right?
Much like:
RESTRICTION 1: START
CLASS 1: START
COMMAND 1
COMMAND 2
IF ACTION IS OK THEN WHOLE RESTRICTION 1 IS OK
IF ACTION IS DUNNO THEN CONTINUE WITH NEXT COMMAND (3) IN CLASS 1
COMMAND 3
COMMAND 4
CLASS 1: END
CLASS 2: START
COMMAND 1
COMMAND 2
CLASS 2: END
CLASS 3: START
COMMAND 1
IF ACTION IS OK THEN WHOLE RESTRICTION 1 IS OK
IF ACTION IS DUNNO THEN
Re: Postgrey and Postfix
Jason Hirsh wrote: I raise this question here because it appears the basic postgrey daemon is running I have a FReebsd 7.0 server with Postfix, amavisd-new, Dovecot to which i added Postgrey I have postgrey runnng as a ps aux grep | postfix shows postgrey 653 0.0 2.4 14384 12052 ?? Is1:53PM 0:00.04 /usr/local/sbin/postgrey --pidfile=/var/run/postgrey.pid --inet=10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey (perl5.8.9) There is no indication in the syslog maillog of any postgrey activity so I am presuming that i have messed up the install or configuration.. postconf -n shows smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains, check_relay_domains is deprecated. Note that check_relay_domains always resolves to either permit or reject. As a consequence, no restrictions after this are evaluated. Use reject_unauth_destination instead, that should fix your problem. reject_rbl_client zen.spamhaus.org bl,reject_rbl_client bl.spamcop.net,reject_rbl_client cbl.abuseat.org,reject_rbl_client safe.dnsbl.sorbs.net,check_policy_service inet:127.0.0.1 cbl.abuseat.org is included in zen.spamhaus.org - no need to query both. sorbs is currently negotiating a change of ownership. Monitor their web site and/or announcement mail list to decide if they still meet your needs after the change is completed. Should be check_policy_service inet:127.0.0.1:10023 Make sure the port matches where postgrey is listening. smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostnamebroken_sasl_auth_clients = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_sender_restrictions = permit_sasl_authenticated, reject_rhsbl_sender dsn.rfc-ignorant.org, reject_rbl_client bl.spamcop.net rfc-ignorant.org is generally better used in a scoring system rather than for outright rejects. Why do you have some RBLs in smtpd_sender_restrictions and some in smtpd_recipient_restrictions? pick one or the other. -- Noel Jones
Re: Reverse DNS requirement
Thomas Gelf schrieb: brian moore wrote: There is always the AOL Rule. Yeah, we are sometimes also using AOL as an example, even if where I live nearly nobody is using it... (Hotmail and Gmail have similar rules, I just don't know where they spell them out.) Hotmail: http://postmaster.msn.com/Guidelines.aspx Gmail: no idea, found nothing but a dummy-user-faq gmx also needs reverse dns http://faq.gmx.de/messages/email/optionen/antispam/1.html -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Postgrey and Postfix
On Aug 4, 2009, at 3:01 PM, Noel Jones wrote: Jason Hirsh wrote: I raise this question here because it appears the basic postgrey daemon is running I have a FReebsd 7.0 server with Postfix, amavisd-new, Dovecot to which i added Postgrey I have postgrey runnng as a ps aux grep | postfix shows postgrey 653 0.0 2.4 14384 12052 ?? Is1:53PM 0:00.04 / usr/local/sbin/postgrey --pidfile=/var/run/postgrey.pid -- inet=10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/ postgrey (perl5.8.9) There is no indication in the syslog maillog of any postgrey activity so I am presuming that i have messed up the install or configuration.. postconf -n shows smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains, check_relay_domains is deprecated. Note that check_relay_domains always resolves to either permit or reject. As a consequence, no restrictions after this are evaluated. Use reject_unauth_destination instead, that should fix your problem. reject_rbl_client zen.spamhaus.org bl,reject_rbl_client bl.spamcop.net,reject_rbl_client cbl.abuseat.org,reject_rbl_client safe.dnsbl.sorbs.net,check_policy_service inet:127.0.0.1 cbl.abuseat.org is included in zen.spamhaus.org - no need to query both. sorbs is currently negotiating a change of ownership. Monitor their web site and/or announcement mail list to decide if they still meet your needs after the change is completed. removed Should be check_policy_service inet:127.0.0.1:10023 Make sure the port matches where postgrey is listening. corrected smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostnamebroken_sasl_auth_clients = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_sender_restrictions = permit_sasl_authenticated, reject_rhsbl_sender dsn.rfc-ignorant.org, reject_rbl_client bl.spamcop.net rfc-ignorant.org is generally better used in a scoring system rather than for outright rejects. Why do you have some RBLs in smtpd_sender_restrictions and some in smtpd_recipient_restrictions? pick one or the other. Partial clean up I had seen similar discussion about douplicaton between smtp_client_restriction and smtp_recipients_restriction. thanks for making the point -- Noel Jones Based on above changes i have ths now postgrey 651 0.0 2.4 14384 12028 ?? Is3:24PM 0:00.04 /usr/ local/sbin/postgrey --pidfile=/var/run/postgrey.pid -- inet=127.0.0.1:10023 -d --user=postgrey --group=postgrey --dbdir=/var/ db/postgrey -verbose (perl5.8.9) postconf -n command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix delay_warning_time = 4h disable_vrfy_command = yes header_checks = regexp:/usr/local/etc/postfix/header_checks home_mailbox = Maildir/ html_directory = no mail_owner = postfix mail_spool_directory = /var/mail/vmail mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man maps_rbl_domains = bl.spamcop.net mydestination = localhost.$mydomain, localhost myhostname = batfish.theoceanwindow-bv.com mynetworks = 127.0.0.0/8, 66.235.184.124, 66.148.83.94 myorigin = $myhostname newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no receive_override_options = no_address_mappings relay_recipient_maps = hash:/usr/local/etc/postfix/relay_recipients sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_tls_note_starttls_offer = yes smtpd_banner = Hi This is the Ocean Window - BV smtpd_helo_required = yes smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,check_helo_access hash:/usr/local/etc/postfix/ helo_access,reject_invalid_hostname,reject_unknown_hostname smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net,reject_rbl_client, check_policy_service inet:127.0.0.1:10023 smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostnamebroken_sasl_auth_clients = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_sender_restrictions = permit_sasl_authenticated smtpd_tls_CAfile = /etc/mail/certs/root.crt smtpd_tls_cert_file = /etc/mail/certs/server.pem smtpd_tls_key_file = /etc/mail/certs/server.key smtpd_tls_loglevel = 3 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/usr/local/etc/postfix/virtual virtual_gid_maps = static:1000 virtual_mailbox_base = /var/mail/vmail virtual_mailbox_domains = /usr/local/etc/postfix/virtual_domains virtual_mailbox_maps = hash:/usr/local/etc/postfix/virtual_mailbox virtual_minimum_uid = 100 virtual_uid_maps = static:1003 and I got a check_access:
Re: Am I an open relay?
On 8/4/2009, Dave (dave.meh...@gmail.com) wrote: For reject_unverified_sender what would be a better way of dealing with it? Only use it for domains which you control or have agreements with... -- Best regards, Charles
I attached the logs and an e-mail end the killed double-bounced
I attached the logs and an e-mail Return-Path: double-bou...@r13151.ovh.net X-Original-To: postmaster Delivered-To: fake...@fakessh.eu Received: by r13151.ovh.net (Postfix) id C5BC91CAD5; Tue, 4 Aug 2009 21:53:28 +0200 (CEST) Date: Tue, 4 Aug 2009 21:53:28 +0200 (CEST) From: mailer-dae...@r13151.ovh.net (Mail Delivery System) To: postmas...@fakessh.eu (Postmaster) Subject: Postfix SMTP server: errors from 6.mail-out.ovh.net[91.121.25.210] ## this ip it's mail provider for hosting Message-Id: 20090804195328.c5bc91c...@r13151.ovh.net X-Evolution-Source: pop://fake...@mail.fakessh.eu/ Mime-Version: 1.0 Transcript of session follows. Out: 220 r13151.ovh.net ESMTP Postfix (2.5.1) In: HELO 6.mail-out.ovh.net Out: 250 r13151.ovh.net In: MAIL FROM:rps-return-25016-fakessh=fakessh...@ml.ovh.net Out: 250 2.1.0 Ok In: RCPT TO:fake...@fakessh.eu Out: 451 4.3.5 Server configuration error In: QUIT Out: 221 2.0.0 Bye
Re: Postgrey and Postfix
On Aug 4, 2009, at 4:23 PM, Brian Evans - Postfix List wrote: Jason Hirsh wrote: Based on above changes i have ths now postgrey 651 0.0 2.4 14384 12028 ?? Is3:24PM 0:00.04 /usr/local/sbin/postgrey --pidfile=/var/run/postgrey.pid --inet=127.0.0.1:10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey -verbose (perl5.8.9) postconf -n smtpd_banner = Hi This is the Ocean Window - BV SASL is disabled with this banner. Use the default as no one will read it. smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net,reject_rbl_client, check_policy_service inet:127.0.0.1:10023 Let's reformat the recipient restrictions for reading: smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client, check_policy_service inet:127.0.0.1:10023 See the error? To Postfix, a comma is whitespace when placed in restriction lists. i see youyr reference but how do I correct? the only error I see is the reject_rbl_client with out a cite the code for the check_policy_service is per all the instructions i hvave seen which state (Add check_policy_service inet:127.0.0.1:10023 to end of smtpd_recipient_restrictions in main.cf) So I guess you lost me
Re: Postgrey and Postfix
Jason Hirsh wrote: On Aug 4, 2009, at 3:59 PM, Noel Jones wrote: Jason Hirsh wrote: On Aug 4, 2009, at 3:01 PM, Noel Jones wrote: Jason Hirsh wrote: I raise this question here because it appears the basic postgrey daemon is running I have a FReebsd 7.0 server with Postfix, amavisd-new, Dovecot to which i added Postgrey I have postgrey runnng as a ps aux grep | postfix shows postgrey 653 0.0 2.4 14384 12052 ?? Is1:53PM 0:00.04 /usr/local/sbin/postgrey --pidfile=/var/run/postgrey.pid --inet=10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey (perl5.8.9) There is no indication in the syslog maillog of any postgrey activity so I am presuming that i have messed up the install or configuration.. postconf -n shows smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains, check_relay_domains is deprecated. Note that check_relay_domains always resolves to either permit or reject. As a consequence, no restrictions after this are evaluated. Use reject_unauth_destination instead, that should fix your problem. ... Based on above changes i have ths now smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains, Did you miss the very important comment about check_relay_domains in my original reply? reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net,reject_rbl_client, check_policy_service inet:127.0.0.1:10023 reject_rbl_client with no RBL to check will likely give a configuration error. and I got a check_access: ja...@kasdivi.com mailto:ja...@kasdivi.com Aug 4 15:40:54 batfish postfix/smtpd[1326]: panic: check_access: dictionary not found: inet:127.0.0.1:10023 Aug 4 15:40:55 batfish postfix/master[1057]: warning: process /usr/local/libexec/postfix/smtpd pid 1326 killed by signal 6 Aug 4 15:40:55 batfish postfix/master[1057]: warning: /usr/local/libexec/postfix/smtpd: bad command startup -- throttling erro message which I assume is related to postgrey?? I expect this is from the extra 'reject_rbl_client' under smtpd_recipient_restrictions I mentioned above. I guess you didn't se my configs I guess you posted the wrong config. smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net,reject_rbl_client,check_policy_service inet:127.0.0.1:10023 See the extra reject_rbl_client just before check_policy_service? that's what's causing your current error. -- Noel Jones
Postfix as outbound relay
And that is as vague as it gets! :-) I've been looking and searching but just can't seem to find what I'm looking for. I need to configure Postfix (and sasl?) so a select group of users from multiple domains can send email. Originally it was to allow some users/domains to send email from (DSL,cable,etc.) providers that block port 25. They are not local users on the mail server. I've found several HOWTOs including Patrick Koetter's smtpauth pages but I'm feeling really thick so just don't seem to get how to fit all the pieces together. Are there any other HOWTOs on setting up Postfix to do smtpauth? Ones for the mail challenged would be best. :-) Of course an example main.cf and its supporting cast of files with the minimum stanzas needed would be perfect. \\||/ Rod --
SOLVED Re: Postgrey and Postfix
On Aug 4, 2009, at 4:56 PM, Noel Jones wrote: Jason Hirsh wrote: On Aug 4, 2009, at 3:59 PM, Noel Jones wrote: Jason Hirsh wrote: On Aug 4, 2009, at 3:01 PM, Noel Jones wrote: Jason Hirsh wrote: I raise this question here because it appears the basic postgrey daemon is running I have a FReebsd 7.0 server with Postfix, amavisd-new, Dovecot to which i added Postgrey I have postgrey runnng as a ps aux grep | postfix shows postgrey 653 0.0 2.4 14384 12052 ?? Is1:53PM 0:00.04 /usr/local/sbin/postgrey --pidfile=/var/run/ postgrey.pid --inet=10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey (perl5.8.9) There is no indication in the syslog maillog of any postgrey activity so I am presuming that i have messed up the install or configuration.. postconf -n shows smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains, check_relay_domains is deprecated. Note that check_relay_domains always resolves to either permit or reject. As a consequence, no restrictions after this are evaluated. Use reject_unauth_destination instead, that should fix your problem. ... Based on above changes i have ths now smtpd_recipient_restrictions = permit_sasl_authenticated, check_relay_domains, Did you miss the very important comment about check_relay_domains in my original reply? reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net,reject_rbl_client, check_policy_service inet: 127.0.0.1:10023 reject_rbl_client with no RBL to check will likely give a configuration error. and I got a check_access: ja...@kasdivi.com mailto:ja...@kasdivi.com Aug 4 15:40:54 batfish postfix/smtpd[1326]: panic: check_access: dictionary not found: inet:127.0.0.1:10023 Aug 4 15:40:55 batfish postfix/master[1057]: warning: process / usr/local/libexec/postfix/smtpd pid 1326 killed by signal 6 Aug 4 15:40:55 batfish postfix/master[1057]: warning: /usr/ local/libexec/postfix/smtpd: bad command startup -- throttling erro message which I assume is related to postgrey?? I expect this is from the extra 'reject_rbl_client' under smtpd_recipient_restrictions I mentioned above. I guess you didn't se my configs I guess you posted the wrong config. who ME?? :) smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net,reject_rbl_client,check_policy_service inet: 127.0.0.1:10023 See the extra reject_rbl_client just before check_policy_service? that's what's causing your current error. that did it final working postconf -n command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix delay_warning_time = 4h disable_vrfy_command = yes header_checks = regexp:/usr/local/etc/postfix/header_checks home_mailbox = Maildir/ html_directory = no mail_owner = postfix mail_spool_directory = /var/mail/vmail mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man maps_rbl_domains = bl.spamcop.net mydestination = localhost.$mydomain, localhost myhostname = x mynetworks = 127.0.0.0/8, xxx myorigin = $myhostname newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no receive_override_options = no_address_mappings relay_recipient_maps = hash:/usr/local/etc/postfix/relay_recipients sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_tls_note_starttls_offer = yes smtpd_banner = smtpd_helo_required = yes smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,check_helo_access hash:/usr/local/etc/postfix/ helo_access,reject_invalid_hostname,reject_unknown_hostname smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net,check_policy_service inet:127.0.0.1:10023 smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostnamebroken_sasl_auth_clients = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_sender_restrictions = permit_sasl_authenticated smtpd_tls_CAfile = /etc/mail/certs/root.crt smtpd_tls_cert_file = /etc/mail/certs/server.pem smtpd_tls_key_file = /etc/mail/certs/server.key smtpd_tls_loglevel = 3 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/usr/local/etc/postfix/virtual virtual_gid_maps = static:1000 virtual_mailbox_base = /var/mail/vmail virtual_mailbox_domains = /usr/local/etc/postfix/virtual_domains virtual_mailbox_maps = hash:/usr/local/etc/postfix/virtual_mailbox virtual_minimum_uid = 100 -- Noel Jones
[LDAP] group of 'memberaddr' gives email's group as well
Hi, I followed and read LDAP_README about groups. Everything works well _EXCEPT_ for the simplest case of a group made only of memberaddr (email only). The group's email is part of the result which obviously becomes a loop back. The configuration only works correctly if a memberdn is present in the group. Is there a simple way to resolve this by tuning the LDAP query ? Like if there is nothing to expand do _not_ use leaf_result_attribute ? Otherwise I guess I must use a different attribute for group's email or move all these groups of emails in a different ou= :(ugly) *Examples*: dn: uid=grouploop, ou=groups, ou=mail, dc=domain, dc=com objectClass: qmailGroup mail: groupl...@domain.com rfc822member: t...@first.com rfc822member: t...@second.com # cat /etc/postfix/groups.cf server_host = ldap.domain.com version = 3 search_base = ou=groups,ou=mail,dc=domain,dc=com query_filter = ((objectClass=qmailGroup)(|(mail=%s)(mailAlternateAddress=%s))) result_attribute = rfc822member special_result_attribute = dnmember leaf_result_attribute = mail # postmap -q groupl...@domain.com ldap:/etc/postfix/groups.cf groupl...@domain.com,t...@first.com,t...@second.com ^ ^ ^ ^ ^ ^ ^ ^ ^ Not good, not good :) But if I have a mixed situation with memberdn (DN only) and memberaddrr (email only). It's OK... dn: uid=tom.mixed, ou=groups, ou=mail, dc=domain, dc=com objectClass: qmailGroup mail: tom.mi...@domain.com rfc822member: t...@first.com dnmember: uid=tom,ou=people,dc=domain,dc=com # postmap -q tom.mi...@domain.com ldap:/etc/postfix/groups.cf t...@first.com, tom-peo...@domain.com Notice: that tom.mi...@domain.com is not part of the result So, if it's normal to not manage groups of emails it might be a good idea to explain how to handle this case in LDAP_README (which is a very good doc by the way) because the example doesn't include this particular case. Or is it my damn cataract ? Cheers, Thomas -- rfc822member = memberaddr in LDAP_README dnmember = memberdm in LDAP_README
Re: [LDAP] group of 'memberaddr' gives email's group as well
Re, # cat /etc/postfix/groups.cf server_host = ldap.domain.com version = 3 search_base = ou=groups,ou=mail,dc=domain,dc=com query_filter = ((objectClass=qmailGroup)(|(mail=%s)(mailAlternateAddress=%s))) result_attribute = rfc822member special_result_attribute = dnmember leaf_result_attribute = mail A solution would be to put rfc822member as a special result attribute. special_result_attribute = dnmember, rfc822member But I don't know if it's /clean/ do to that. BTW, I'm using postfix 2.5.5 (Debian Lenny) Cheers, Thomas
Re: [LDAP] group of 'memberaddr' gives email's group as well
As I understand it, special_result_attribute is expected to be a DN type, since it then uses the results of that to look up the DNs referenced, trying to find result_attribute under them. It wouldn't be valid to have rfc822member listen in special_result_attribute. Adrian Thomas wrote: Re, # cat /etc/postfix/groups.cf server_host = ldap.domain.com version = 3 search_base = ou=groups,ou=mail,dc=domain,dc=com query_filter = ((objectClass=qmailGroup)(|(mail=%s)(mailAlternateAddress=%s))) result_attribute = rfc822member special_result_attribute = dnmember leaf_result_attribute = mail A solution would be to put rfc822member as a special result attribute. special_result_attribute = dnmember, rfc822member But I don't know if it's /clean/ do to that. BTW, I'm using postfix 2.5.5 (Debian Lenny) Cheers, Thomas
how to forbid the bounced mail?
Hi All, I want to do a test with postfix. For example, I will relay many mails to postfix and postfix delivery maiils to mda. But you know, mda may not be stable enough, so mda would not work occasionally. At this time, the postfix would bounce mails, I can not hope to see it. So, how to forbid the bounced mail? Thanks!
[Postfix-User]Authenticated User Using Dovecot Cannot Relay
Sorry if this question already asked, I'm configuring postfix for SMTP AUTH with dovecot and here's my main.cf configuration alias_maps = hash:/etc/aliases broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 html_directory = no inet_interfaces = 127.0.0.1, 192.168.101.245 mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mydomain = kantor.com myhostname = ns-1.kantor.com newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES sample_directory = /usr/share/doc/postfix-2.3.3/samples sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_relay_domains smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/pki/tls/certs/mail.kantor.com.cert smtpd_tls_key_file = /etc/pki/tls/private/mail.kantor.com.key smtpd_tls_loglevel = 1 smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_cache smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 and if my client try to send email from outside the network in maillog, it's display : Aug 5 10:20:37 ns-1 dovecot: pop3-login: Login: user=samuel, method=PLAIN, rip=:::192.169.54.147, lip=:::192.168.101.245, TLS Aug 5 10:20:37 ns-1 dovecot: POP3(samuel): Disconnected: Logged out top=0/0, retr=0/0, del=0/0, size=0 Aug 5 10:21:15 ns-1 postfix/smtpd[15817]: connect from unknown[192.169.54.147] Aug 5 10:21:15 ns-1 postfix/smtpd[15817]: setting up TLS connection from unknown[192.169.54.147] Aug 5 10:21:15 ns-1 postfix/smtpd[15817]: TLS connection established from unknown[192.169.54.147]: TLSv1 with cipher RC4-MD5 (128/128 bits) Aug 5 10:21:15 ns-1 postfix/smtpd[15817]: NOQUEUE: reject: RCPT from unknown[192.169.54.147]: 554 5.7.1 imanuel.a.si...@rumah.com: Relay access denied; from=sam...@kantor.com to=imanuel.a.si...@rumah.com proto=ESMTP helo=IBMLaptop Aug 5 10:21:18 ns-1 postfix/smtpd[15817]: disconnect from unknown[192.169.54.147] if there's some mistake that i made in my main.cf or something else that's all from me thank's a lot your kind help -- Regards Samuel Sappa,
Re: [Postfix-User]Authenticated User Using Dovecot Cannot Relay
On Tuesday 04 August 2009 23:12:56 Samuel Sappa wrote: Sorry if this question already asked, Lots of times. I'm configuring postfix for SMTP AUTH with dovecot and here's my main.cf configuration [snip] and if my client try to send email from outside the network in maillog, it's display : Aug 5 10:20:37 ns-1 dovecot: pop3-login: Login: user=samuel, method=PLAIN, rip=:::192.169.54.147, lip=:::192.168.101.245, TLS Aug 5 10:20:37 ns-1 dovecot: POP3(samuel): Disconnected: Logged out top=0/0, retr=0/0, del=0/0, size=0 These are Dovecot POP3 logs, not Postfix. Aug 5 10:21:15 ns-1 postfix/smtpd[15817]: connect from unknown[192.169.54.147] Aug 5 10:21:15 ns-1 postfix/smtpd[15817]: setting up TLS connection from unknown[192.169.54.147] Aug 5 10:21:15 ns-1 postfix/smtpd[15817]: TLS connection established from unknown[192.169.54.147]: TLSv1 with cipher RC4-MD5 (128/128 bits) And that is TLS, not SASL AUTH. At this point in the logs there should be a line showing that AUTH was successful (or failed.) Aug 5 10:21:15 ns-1 postfix/smtpd[15817]: NOQUEUE: reject: RCPT from unknown[192.169.54.147]: 554 5.7.1 imanuel.a.si...@rumah.com: Relay access denied; from=sam...@kantor.com to=imanuel.a.si...@rumah.com proto=ESMTP helo=IBMLaptop Aug 5 10:21:18 ns-1 postfix/smtpd[15817]: disconnect from unknown[192.169.54.147] if there's some mistake that i made in my main.cf or something else that's all from me thank's a lot your kind help There is no evidence that the client attempted to AUTH. The only glaring error in your config, check_relay_domains, is not really an error at all. (It's harmless, but it shows that you have been looking at old, outdated documentation, perhaps such as a poorly-understood third-party HOWTO.) What we've got here is ... failure to authenticate. (Apologies to the late Strother Martin.) This is a very common problem with Microsoft clients. Test and ensure it works with a better client, first. Then Google postfix-users outlook auth to find the scores of other people with the same issue. A gratuitous hint: add mechanism to the search, and you will probably find the second best answer. The best answer: refuse to support broken mail clients! -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Reverse DNS requirement
On Aug 4, 2009, at 3:42, Thomas Gelf tho...@gelf.net wrote: the person who did not correctly set up the network is to be blamed, if you have equipment acting as MTA it should be configured the right way, otherwise use a relay server SHOULD be blamed? Yes. But the blame will fall on the mail admin. The mail was sent, YOU caused the server to reject it.
Re: Question regarding Restriction Classes
On Tuesday 04 August 2009 13:51:31 Steve wrote: But I don't think this is it. What you want to do is make subclasses that continue on into your restrictions. This statement I don't understand. Allow me to rephrase what I have understood from the above paragraph: Restrictions are mubmle_restrictions (aka (smtpd_client|smtpd_helo|smtpd_sender|smtpd_recipient|smtpd_data |smtpd_end_of_data|smtpd_etrn)_restrictions) What are subclasses? I don't know what that is? A restriction is something that can be put in smtpd_*_restrictions. smtpd_*_restrictions themselves are each estriction stages. Subclass is not a Postfix term. I was using it to mean subdivide your restriction classes into smaller classes. And I think you got that part. But I understand now better. Your text above helped me. And I have read now again more about restriction classes and I think I get it. My viewpoint changed. I was looking at the whole topic with a developer eye but that's wrong. I see now that the way restriction classes are handled is differently then I expected. It's more a way of extending the processing by adding blocks of commands on condition then branching/jumping inside the processing flow. Indeed, while restriction classes can make smtpd(8) restrictions akin to a programming language, they do lack branching and jumping features. But my simplified approach is a workaround that should ensure that the aspirin bottle never strays too far from your desk. :) I had a horribly bad headache this very evening, in fact. Just a coincidence? I doubt it. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: how to forbid the bounced mail?
On Aug 4, 2009, at 9:00 PM, Chookiex wrote: Hi All, I want to do a test with postfix. For example, I will relay many mails to postfix and postfix delivery maiils to mda. But you know, mda may not be stable enough, so mda would not work occasionally. At this time, the postfix would bounce mails, I can not hope to see it. So, how to forbid the bounced mail? It is generally not in your control. The sending server should know to retry again later, for at the least, a few hours. I retry 12 hours by default, many others use a much greater time. A second line of protection would be a secondary MX, which will accept all emails and hold them until your primary comes back online. I have decided that due to spammers the secondary MX is not worth it for me. Spammers like to target a secondary MX directly, and I was unable to keep the secondary and primary in sync with regard to anti spam measures and configs. I figured, most retry intervals are long enough that I should be able to get some form of limited receiving server back online within that time window. -- Scott * If you contact me off list replace talklists@ with scott@ *
