Re: non delivery notificaitons
Am 19.02.2015 um 20:32 schrieb Vernon Fort: I have a barracuda spam firewall that my postfix setup simply relays emails to for scanning, via the transport file complete wrong setup - the barracuda crap (we used it for nearly a decade and it became unacceptable for so much reaosns) is deigned to run as MX and deliver clean messages to your postfix anything else is pore nonsense *because* it makes you to a backscatter and there is nothing you can fix that DISCARD is a complete stupid action - unconditionally you have to REJECT the mail and even for that Barracuda Networks is way too stupid for many cases, but if you accept any message you have to deliver it - not because of the junk - beause of false positives *always* happening and without the sender and/or the RCPT know about the spam-hit because you silent discard you do much more harm than spam ever could do don't accept messages you won't deliver if you can't do that your setup is just wrong
Re: non delivery notificaitons
besides that a off-list reply is rude and I mean really 100 % Mails containing certain words is laughable - if it would be *that* easy spam won't exist The disadvantage of REJECT is that you tell the spammer hey there is a spam filter there and the spammer will make their ways around it. is *complete bullshit* and if you would have any clue about spam you would know that - with your ACCEPT and discard you make an invitation for spammers - see attached mailgraph sortly after replace a barracuda device silently discard spam with a sane solution reject it fact is that spammers don't read repsonse messages and many treat the address as invalid after repeated reejcts for hwatever reason as well as dictionary attacks continue after success because reject of the contentfilter - that's reality proven by logs and years of expierience __ if you can reject a mail than *do it* if you can't reject a amil deliver it period Am 19.02.2015 um 21:21 schrieb Sebastian Nielsen: I dont agree. I would say that DISCARD is okay - only when a mail is guranteed 100% to be spam, malformed or in other way disadmissible. With 100%, I mean really 100 %. Mails containing certain words about illegal copies of certain very expensive clock brands, is one example, and in this case I mean that you use a AND logic between the words. Legit mail do NEVER EVER contain words about illegal copies of certain very expensive clocks to take a example. I have a couple of hand-written rules that DISCARD mail, but these are clear cuts, they either only look on the subject line for certain spammy words that I know that legit mail never will contain, or it will contain a very strict body rule that would guranteed to only hit on spam. The disadvantage of REJECT is that you tell the spammer hey there is a spam filter there and the spammer will make their ways around it. If you instead silently discard it, spammer will think the mail got through and not bother with that mail server anymore. So a multilayered tier is better, for example: 1: DISCARD all mails that are blatant spam or malformed in a such non-RFC way that its basically not mail, or mails that have a DMARC policy of discard when SPF and DKIM auth fails. 2: REJECT any mail that are any less than 100% sure its spam, or mails that just arent 100% strict about RFCs, but they can still be parsed without problems, or contain other authentication errors. 3: Then you do some final checks on mail, possible deliver it to inbox with a [Possibly Spam] subject tag or you consider the mail ham and pass it unmodified to receiver. -Ursprungligt meddelande- From: li...@rhsoft.net Sent: Thursday, February 19, 2015 9:00 PM To: postfix-users@postfix.org Subject: Re: non delivery notificaitons Am 19.02.2015 um 20:32 schrieb Vernon Fort: I have a barracuda spam firewall that my postfix setup simply relays emails to for scanning, via the transport file complete wrong setup - the barracuda crap (we used it for nearly a decade and it became unacceptable for so much reaosns) is deigned to run as MX and deliver clean messages to your postfix anything else is pore nonsense *because* it makes you to a backscatter and there is nothing you can fix that DISCARD is a complete stupid action - unconditionally you have to REJECT the mail and even for that Barracuda Networks is way too stupid for many cases, but if you accept any message you have to deliver it - not because of the junk - beause of false positives *always* happening and without the sender and/or the RCPT know about the spam-hit because you silent discard you do much more harm than spam ever could do don't accept messages you won't deliver if you can't do that your setup is just wrong
Re: Sanity check
Am 19.02.2015 um 12:32 schrieb John: On 2/16/2015 10:29 PM, Viktor Dukhovni wrote: smtp_tls_cert_file = /root/ssl/certs/$mydomain.mail.pem smtp_tls_key_file = /root/ssl/private/$mydomain.mail.key Are there any destinations for which you need client certs to gain access? If not set these empty. I thought these were needed for TLS. I must be a /little/ confused. Is it the sender or the receiver that initiates TLS? From your comment to remove them, it must be the receiver, correct? that's not the point smtp_ settings are client normally the client don't need a cert for TLS your browser and mail-client don't use one too
Re: Sanity check
Am 19.02.2015 um 13:30 schrieb John: On 2/19/2015 6:35 AM, li...@rhsoft.net wrote: Am 19.02.2015 um 12:32 schrieb John: On 2/16/2015 10:29 PM, Viktor Dukhovni wrote: smtp_tls_cert_file = /root/ssl/certs/$mydomain.mail.pem smtp_tls_key_file = /root/ssl/private/$mydomain.mail.key Are there any destinations for which you need client certs to gain access? If not set these empty. I thought these were needed for TLS. I must be a /little/ confused. Is it the sender or the receiver that initiates TLS? From your comment to remove them, it must be the receiver, correct? that's not the point smtp_ settings are client normally the client don't need a cert for TLS your browser and mail-client don't use one too Hmmm. How does this affect Submission? what did you not understand in smtp_ settings are client? postfix smtp client = OUTBOUND mail and by all respect *that* is basic knowledge when you touch main.cf and in general don't change settings you obviously have no clue what they are doing
Re: Sanity check
Am 19.02.2015 um 13:22 schrieb John: On 2/19/2015 6:49 AM, Richard James Salts wrote: On Thu, 19 Feb 2015 06:32:29 John wrote: On 2/16/2015 10:29 PM, Viktor Dukhovni wrote: smtp_tls_cert_file = /root/ssl/certs/$mydomain.mail.pem smtp_tls_key_file = /root/ssl/private/$mydomain.mail.key Are there any destinations for which you need client certs to gain access? If not set these empty. I thought these were needed for TLS. I must be a /little/ confused. Is it the sender or the receiver that initiates TLS? From your comment to remove them, it must be the receiver, correct? These settings are saying to use a specific certificate when connecting to another server with a specific client certificate where mutual trust is needed, e.g. where you were connecting to a smarthost that used the certificate to authenticate you. So we are talking about MTA to MTA connectivity. ?? surely and you should know that when you touch a setting http://www.postfix.org/smtp.8.html http://www.postfix.org/smtpd.8.html
Re: Sanity check
Am 19.02.2015 um 14:11 schrieb John: On 2/19/2015 7:48 AM, li...@rhsoft.net wrote: Am 19.02.2015 um 13:30 schrieb John: On 2/19/2015 6:35 AM, li...@rhsoft.net wrote: Am 19.02.2015 um 12:32 schrieb John: On 2/16/2015 10:29 PM, Viktor Dukhovni wrote: smtp_tls_cert_file = /root/ssl/certs/$mydomain.mail.pem smtp_tls_key_file = /root/ssl/private/$mydomain.mail.key Are there any destinations for which you need client certs to gain access? If not set these empty. I thought these were needed for TLS. I must be a /little/ confused. Is it the sender or the receiver that initiates TLS? From your comment to remove them, it must be the receiver, correct? that's not the point smtp_ settings are client normally the client don't need a cert for TLS your browser and mail-client don't use one too Hmmm. How does this affect Submission? what did you not understand in smtp_ settings are client? postfix smtp client = OUTBOUND mail and by all respect *that* is basic knowledge when you touch main.cf and in general don't change settings you obviously have no clue what they are doing DON'T get snarky and yell at me, I am trying to understand something here!!! http://www.postfix.org/postconf.5.html#smtp_tls_cert_file that would be the start and contains Do not configure client certificates unless you must present client TLS certificates to one or more servers. Client certificates are not usually needed, and can cause problems in configurations that work well without them there is a own anchor link for *any* postfix setting in the docs I think I got a little confused, when Victor used the term client. Not his fault I was thinking in terms of the client being the writer of the email using a MUA. Up until then I thought that smtp was for sending between MTAs, and that smtpd was for receiving both from MTAs and MUAs. The main difference being that /good/ practice is that MTAs us port 25 and MUAs use 587 it's way simpler to express: * smtpd: accepting inbound connections (server) * smtp: make outbound connections (client)
Re: Support for Cassandra CQL database lookup table
Am 19.02.2015 um 23:20 schrieb List: We would like to use the Cassandra database to persist the state of abusive IPs which we would block from connecting in one of the smtpd_xxx_restrictions clauses. We have systems that exist in multiple data centers and Cassandra works really well for persisting data between them, but Postfix does not support Cassandra and specifically the CQL language as a lookup table. Is this planned for any releases in the near future? why don't you just feed http://www.corpit.ru/mjt/rbldnsd.html with that IP's and use it with reject_rbl_client? that scales much better because it is written and optimized for that task
Re: non delivery notificaitons
Am 19.02.2015 um 23:10 schrieb Viktor Dukhovni: On Thu, Feb 19, 2015 at 09:36:08PM +0100, li...@rhsoft.net wrote: The disadvantage of REJECT is that you tell the spammer hey there is a spam filter there and the spammer will make their ways around it. is *complete bullshit* and if you would have any clue about spam ... I think it is time for you to decide whether you're on this list to help people or merely to insult them. If the former, please refrain from similar comments. If the latter, please find another list. frist: this was a response to a *off-list* reply second: read the reply i gave the OP which *was* helpful Please direct any disagreement with the above to /dev/null. no, not if you quote *completly* out of context Final warning, you will be dropped from the list (again) if you do not tone down your responses, or choose to contest this notice. nice style: i attack you but you are not allowed to respond
Re: TLS library problem
Am 19.02.2015 um 16:53 schrieb st...@thornet.co.uk: We have lots of these in the logs warning: TLS library problem: 15696:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1256:SSL alert number 46: Should I be worried? without the realted loglines above and below, no context and without postconf -n who knows - frankly you did even not say if it's incoming or outgoing mail
Re: using conditional other smtp
Am 18.02.2015 um 09:26 schrieb Gianluca Gargiulo: my postfix directly send email, but in some conditions based on *@domain-part* i'd like relay the email to another smtp server that require credentials based on sender. Can i configure postfix for this scenario? http://www.postfix.org/transport.5.html P.S: don't post HTML and signatures to mailing-lists
Re: Dovecot on a separate server as LDA
Am 18.02.2015 um 18:26 schrieb Орхан Ибад-оглы Гасымов: I need an advice about a simple (I guess) thing. When Postfix and Dovecot are running on the same machine, then to specify Dovecot as LDA, I use this command in main.cf http://main.cf: mailbox_command = /usr/local/libexec/dovecot/dovecot-lda -f $SENDER -a $RECIPIENT But if Dovecot is running on a different machine, how should I achieve the same result? Obviously I can't use the same command, as there's no dovecot-lda on the Postfix VM http://wiki2.dovecot.org/LMTP http://www.postfix.org/lmtp.8.html
Re: postmulti fatal error with 3.0.0
Am 18.02.2015 um 19:59 schrieb Andreas: Am 2/18/2015 um 18:39 schrieb Viktor Dukhovni: With 3.0.0 Linux distributions should start using the upstream default. This does mean that users should remove explicit legacy default settings of daemon_directory from their main.cf files. Distribution package upgrades will need to update or drop obsolete daemon_directory settings from all installed Postfix instances. Is this a suggestion or restriction? If it is a suggestion, then both ways should be possible. But as i understood Witse correctly, having postfix executables and libs share a directory is explicitly forbidden (and forcing every linux distribution out there to follow an FHS *draft*). Accepted (maybe mention in docs). Then you should at least be consistent and enforce this restriction in the master process as well FHS draft or not - look when the last update of FHS was it also don't contain /run present on 99% of recent linux setups
header_checks BCC multiple rules hit
is it intentional that if a message hits more than one Regex that it creates also more than once BCC like below? it's little bit surprising because in all known cases the first rule hit's and the evaluation of the file is stopped the intention of the spamfilter+inbox...@rhsoft.net is to get ham-train candiates collected in a seperate folder while the inbox is checked for spam-candidates /^X\-Spam\-Flag: Yes/ BCC spamfil...@rhsoft.net /^X\-Spam\-Report:.*(BAYES_50)/ BCC spamfilter+inbox...@rhsoft.net
Re: Transitioning from cyrus-SASL to dovecot-SASL
Am 17.02.2015 um 15:43 schrieb Rich Shepard:
I'm not a professional SysAdmin or network admin but have been
running my
own smtpd using cyrus-SASL for years. I want now to transition to using
dovecot-SASL and have difficulty correctly configuring dovecot.
Reading the postfix/dovecot Web pages and following the links, I created
/etc/pam.d/dovecot. On the page
http://wiki2.dovecot.org/PasswordDatabase/PAM
page, under Service Name, I read, By default Dovecot uses dovecot as the
PAM service name, so the configuration is read from /etc/pam.d/dovecot yet
the two examples are for /etc/pam.d/imap ../pop3 and /etc/pam.d/mail. I
chose to use the content for /etc/pam.d/dovecot as,
passdb {
driver = pam
args = %s
}
Is this correct?
no idea where you found anything related to PAM since when you are
running already dovecot the authentication works for IMAP/POP3 and you
miss only the postfix integration for SASL
DOVECOT:
# configure backend for postfix sasl-auth
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
}
POSTFIX:
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
Re: header_checks BCC multiple rules hit
Am 17.02.2015 um 17:55 schrieb Viktor Dukhovni: On Tue, Feb 17, 2015 at 05:51:07PM +0100, li...@rhsoft.net wrote: Is it intentional that if a message hits more than one Regex that it creates also more than once BCC like below? it's little bit surprising because in all known cases the first rule hit's and the evaluation of the file is stopped On a per-header line basis. Postfix header checks are *simple* not sure how the word simple is meant in the context it's intentional or it's not intentional would be clearer simple in the from all are proceeded or simple in the form stop after the first one hits like OK / DUNNO which is not the case fact is that both fire: /^X\-Spam\-Flag: Yes/ BCC spamfil...@rhsoft.net /^X\-Spam\-Report:.*(BAYES_50)/ BCC spamfilter+inbox...@rhsoft.net Feb 17 17:40:50 localhost postfix/spamfilter/smtpd[14219]: 3kmnxG0DTzz2W: client= Feb 17 17:40:50 localhost postfix/cleanup[14221]: 3kmnxG0DTzz2W: message-id=* Feb 17 17:40:50 localhost postfix/cleanup[14221]: 3kmnxG0DTzz2W: bcc: header X-Spam-Flag: Yes from ; from= to=ha...@rhsoft.net proto=ESMTP helo=: spamfil...@rhsoft.net Feb 17 17:40:50 localhost postfix/cleanup[14221]: 3kmnxG0DTzz2W: bcc: header X-Spam-Report: ??* -0.0 CUST_DNSWL_2 RBL: list.dnswl.org (No Trust)??* [192.155.81.197 listed in list.dnswl.org]??* -0.2 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)??* [192.155.81.197 lis from ; from= to=ha...@rhsoft.net proto=ESMTP helo=: spamfilter+inbox...@rhsoft.net Feb 17 17:40:50 localhost postfix/qmgr[14136]: 3kmnxG0DTzz2W: from=, size=4860, nrcpt=3 (queue active) Feb 17 17:40:50 localhost postfix/lmtp[14222]: 3kmnxG0DTzz2W: to=ha...@rhsoft.net, relay=127.0.0.1[127.0.0.1]:24, delay=0.14, delays=0.01/0/0/0.12, dsn=2.0.0, status=sent (215 Recipient ha...@rhsoft.net OK) Feb 17 17:40:50 localhost postfix/lmtp[14222]: 3kmnxG0DTzz2W: to=spamfilter+inbox...@rhsoft.net, relay=127.0.0.1[127.0.0.1]:24, delay=0.14, delays=0.01/0/0/0.12, dsn=2.0.0, status=sent (215 Recipient spamfilter+inbox...@rhsoft.net OK) Feb 17 17:40:50 localhost postfix/lmtp[14222]: 3kmnxG0DTzz2W: to=spamfil...@rhsoft.net, relay=127.0.0.1[127.0.0.1]:24, delay=0.14, delays=0.01/0/0/0.12, dsn=2.0.0, status=sent (215 Recipient spamfil...@rhsoft.net OK) Feb 17 17:40:50 localhost postfix/qmgr[14136]: 3kmnxG0DTzz2W: removed
Re: header_checks BCC multiple rules hit
Am 17.02.2015 um 19:05 schrieb Viktor Dukhovni: On Tue, Feb 17, 2015 at 07:02:27PM +0100, li...@rhsoft.net wrote: (*) The exceptions are REJECT and DISCARD which terminate further table lookups because the decision is obviously final. and DUNNO NO! That's not a final decision, processing of more headers continues accepted but surprising, i would have thougth it's even in header_checks like in access tables a way to place rules on top to skip anything after - not needed anything like reject until now in context of header_checks, hence unclear That is absolutely incorrect. REJECT, OK, DUNNO, DISCARD are final inside *the same* access table maybe there is a border-case i never faced where it's not so For each lookup key. Each header line is a separate lookup thanks that's what i wanted to clarify
Re: header_checks BCC multiple rules hit
Am 17.02.2015 um 19:14 schrieb Wietse Venema: li...@rhsoft.net: Am 17.02.2015 um 18:46 schrieb Wietse Venema: li...@rhsoft.net: is it intentional that if a message hits more than one Regex that it creates also more than once BCC like below? it's little bit surprising Of course. If more than one header line matches the table, then more than one action will execute(*). Why is that surprising? [bcc] header_checks works as documented. If you want a different BCC action then it will have to have a different name. agreed, something like BCC-FINAL to express clear the desired result (*) The exceptions are REJECT and DISCARD which terminate further table lookups because the decision is obviously final. and DUNNO Nope. As the documentation says: DUNNO Pretend that the input line did not match any pattern, and INSPECT THE NEXT INPUT LINE. This is basic stuff. well, yes, i compared the behavior with access tables like hundrets of PTR rules with DUNNO rules on top for known false positives
Re: header_checks BCC multiple rules hit
Am 17.02.2015 um 18:46 schrieb Wietse Venema: li...@rhsoft.net: is it intentional that if a message hits more than one Regex that it creates also more than once BCC like below? it's little bit surprising Of course. If more than one header line matches the table, then more than one action will execute(*). Why is that surprising? because you can't make decisions who get what BCC and there is a practical difference if a message got above 5.5 points by whatever rule or has a BYES_%0 (*) The exceptions are REJECT and DISCARD which terminate further table lookups because the decision is obviously final. and DUNNO because in all known cases the first rule hit's and the evaluation of the file is stopped That is absolutely incorrect. REJECT, OK, DUNNO, DISCARD are final inside *the same* access table maybe there is a border-case i never faced where it's not so the intention of the spamfilter+inbox...@rhsoft.net is to get ham-train candiates collected in a seperate folder while the inbox is checked for spam-candidates /^X\-Spam\-Flag: Yes/ BCC spamfil...@rhsoft.net /^X\-Spam\-Report:.*(BAYES_50)/ BCC spamfilter+inbox...@rhsoft.net
Re: header_checks BCC multiple rules hit
Am 17.02.2015 um 19:29 schrieb Viktor Dukhovni: On Tue, Feb 17, 2015 at 07:14:51PM +0100, li...@rhsoft.net wrote: Am 17.02.2015 um 19:05 schrieb Viktor Dukhovni: On Tue, Feb 17, 2015 at 07:02:27PM +0100, li...@rhsoft.net wrote: (*) The exceptions are REJECT and DISCARD which terminate further table lookups because the decision is obviously final. and DUNNO NO! That's not a final decision, processing of more headers continues accepted but surprising, i would have thougth it's even in header_checks like in access tables a way to place rules on top to skip anything after - not needed anything like reject until now in context of header_checks, hence unclear Only surprising if your mental model is incorrect, with header checks applying to all headers at once. Postfix header checks are not like Sieve, the rules apply one header line at a time maybe, depends on the model the human versus the implementation :-) however, to do people reading that thread something good below the solution to avoid duplicates by modify the headers spmassassin generates and adopt the Regex rules finally for legal reasons you need only a sieve-script with keep for optin-users and discard for anything else and to cover also BCC and have relieable headers for the sieve-script: http://comments.gmane.org/gmane.mail.postfix.user/193456 main.cf: header_checks = pcre:/etc/postfix/header_checks_smtpd.cf nested_header_checks = mime_header_checks = /etc/postfix/header_checks_smtpd.cf: /^X\-Spam\-Flag: Yes/ BCC spamfil...@rhsoft.net /^X\-Spam\-Report: Flag: No.*(BAYES_80|BAYES_95|BAYES_99)/ BCC spamfil...@rhsoft.net /^X\-Spam\-Report: Flag: No.*(BAYES_50)/ BCC spamfilter+inbox...@rhsoft.net Spamassassin local.cf: clear_headers fold_headers 1 add_header spam Flag _YESNO_ add_header all Status _YESNO_, score=_SCORE_, tag-level=_REQD_, block-level=8.0 report_safe 0 add_header all Report Flag: _YESNO_, _REPORT_ rewrite_header Subject [SPAM] ___ (block-level=8.0) is hardcoded or template based in case of a spamass-milter setup with a reject score
Re: Next Dumb question - mynetworks
Am 15.02.2015 um 13:37 schrieb John: I think I am asking the wrong question. What would be the effects of setting /mynetworks/ to 127.0.0.1/8 and ::1/128? I assume that I would need these in order to allow inter-process communication on the server. Could I remove the /permit_mynetworks/ stanza in my restriction classes in main? I suspect that I would need to keep them in master, or could I remove them here as well? Bearing in mind that we want to restrict our users to authenticated submission access only you don't need permit_mynetworks anywhere by definition until you want to override restrictions based on, well, mynetworks our inbound spamfilter as example don't use it at all with the exception that mynetworks contains the LAN netmask to bypass postscreen implicit postscreen_access_list (default: permit_mynetworks)
Re: helo_checks
Am 14.02.2015 um 11:30 schrieb LuKreme: Has anyone had any sort of issue with a check like this: /(unknown|localhost|localdomain|lan|home|example|local|lokal)$/ REJECT Mailserver name in private namespace I’ve noticed a lot of commercial non-spam email hitting this recently (for example, landmarktheatres ticket confirmations, a local restaurant's email verification for signup, and some others along those lines). In fact, the split between obvious spam and no-spam seems to be about 80/20 with low hitrate either way. Yes, I know their mail servers are mis-configured put any PTR and HELO checks at the *bottom* of your restrictions and conigure the SPF check as well as much as possible DNSWL to skip them hence no real problems here while we update the checks automatically once per day by the current http://data.iana.org/TLD/tlds-alpha-by-domain.txt to not miss new TLD's and jeject any non-existing /etc/python-policyd-spf/policyd-spf.conf Mail_From_pass_restriction = OK
Re: How do I get User/Password authentication on 587 only for relaying
Am 14.02.2015 um 15:13 schrieb Nick Howitt: Up to now I have been using postfix as an internal server at home relaying messages from internal clients to my ISP, but also receiving mail on port 25. Now my wife has an Android, I'd like to enable her to send mail through the server when out and about. With the options I have with the ClearOS front end, to allow user/pass authentication it sets: smtpd_sasl_auth_enable = yes smtpd_tls_auth_only = no Unfortunately this opens up user/pass authenticated relaying to port 25 as well as 587 and is vulnerable to to being brute forced remove smtpd_sasl_auth_enable = yes from main.cf and add -o smtpd_sasl_auth_enable=yes to the submission entry in master.cf
Re: cannot send emails - NOQUEUE: reject: RCPT
Am 14.02.2015 um 19:16 schrieb Viktor Dukhovni: On Sat, Feb 14, 2015 at 12:53:46PM -0500, Brad s wrote: # postconf -n smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unauth_pipelining, reject_invalid_hostname, reject_rbl_client list.dsbl.org, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl-xbl.spamhaus.org The above does not attempt to enforce relay access control (contains no restrictions that accept selectively and reject by default), and therefore Postfix will refuse all inbound mail the default action is permit and by all respect, the smtpd_recipient_restrictions above are correct and will accept inbound mail but it should contain reject_unauth_destination *after* permit_sasl_authenticated
Re: cannot send emails - NOQUEUE: reject: RCPT
Am 14.02.2015 um 18:53 schrieb Brad s: # postconf -n postconf: warning: /usr/local/etc/postfix/main.cf http://main.cf/: unused parameter: smtpd_relay_restriction=permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination postconf: warning: /usr/local/etc/postfix/main.cf http://main.cf/: unused parameter: contencontent_filter=smtp-amavis:[127.0.0.1]:10024 postconf: warning: /usr/local/etc/postfix/main.cf http://main.cf/: unused parameter: virtual_create_maildirsize=yes postconf: warning: /usr/local/etc/postfix/main.cf http://main.cf/: unused parameter: virtual_mailbox_extended=yes you see those warnings? smtpd_relay_restriction != smtpd_relay_restrictions there is not maillog in your post! 535 5.7.8 Error: authentication failed is a pretty clear response # telnetr2d2.ex-mailer.com http://r2d2.ex-mailer.com/ 25 Trying 2001:19f0:7000:8945::64... telnet: connect to address 2001:19f0:7000:8945::64: Connection refused Trying 107.191.60.48... Connected tor2d2.ex-mailer.com http://r2d2.ex-mailer.com/. Escape character is '^]'. 220r2d2.ex-mailer.com http://r2d2.ex-mailer.com/ ESMTP Postfix ehlobr...@nyctelecomm.com mailto:br...@nyctelecomm.com 250-r2d2.ex-mailer.com http://250-r2d2.ex-mailer.com/ 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN AUTH PLAIN kkBuMQ== 535 5.7.8 Error: authentication failed: quit 221 2.0.0 Bye
Re: cannot send emails - NOQUEUE: reject: RCPT
Am 14.02.2015 um 19:36 schrieb Brad s: Actually the logs are pretty clear then you have no problem to solve? match_list_match:ool-4355399b.dyn.optonline.net http://ool-4355399b.dyn.optonline.net: no match Where the possibility of there ever being a match are slim and none. The server is on a dynamic network. how is that relevnt to the subject? The only way that info is found is via verbose logging. I UNDERSTAND THAT POSTFIX WON'T SHUT UP ABOUT MATCHING NETWORKS. I tried to everything from deleting mynetwork entirely from the conf to setting it to 0.0.0.0 /0.0.0.0 http://0.0.0.0 so what's the issue then if all is working you reported cannot send emails - NOQUEUE: reject: RCPT with no *non-debug* logs and if you seek help you need to provide that logs from connection to reject or have look rule out the problem at your own
Re: cannot send emails - NOQUEUE: reject: RCPT
Am 14.02.2015 um 20:14 schrieb Brad s: ? Verbose logs in no way indicates software functioning properly. unbelievebale * you don't find the problem otherwise the thread won't exist * nobody but you is interested in verbose logs * so if you need help from others provide the informations asked or have a ncide day by find the solution at your own If I add my ip address to mynetworks (which is dead wrong) I can see the mail make it farther in the system but then gets caught in match classes for the destination domain (which is also dead wrong). it should be 0.0.0.0 any IP source / any destination domain ONE LAST TIME: * disable verbose logging * post the *relevant* log lines from connection to reject do you have at least fixed the typo smtpd_relay_restriciton postconf shows you clearly and two people pointed at?
Re: cannot send emails - NOQUEUE: reject: RCPT
Am 14.02.2015 um 20:29 schrieb Brad s: Here are your logs without verbose logging https://bpaste.net/show/79c1ea5f65e6 Can see anything now. But you were very insistent forget it - i have no nicer words than you are not able to privide basic informations and hence should refrain to maintain servers because a) you repeatly post links instead inline informations and b) no default postfix logging would miss the smtpd lines so there are three options for the logging: * you posted (intentionally) a random snippet from the maillig * you misconfigured logging badly * your syslog daemon is broken or logging elsewehere than you look however, i am out of this useless thread because i refuse to waste my time with people not following basic instructions of the list welcome message
Re: helo_checks
Am 14.02.2015 um 23:37 schrieb LuKreme: On 14 Feb 2015, at 04:39 , li...@rhsoft.net wrote: Am 14.02.2015 um 11:30 schrieb LuKreme: Has anyone had any sort of issue with a check like this: /(unknown|localhost|localdomain|lan|home|example|local|lokal)$/ REJECT Mailserver name in private namespace I’ve noticed a lot of commercial non-spam email hitting this recently (for example, landmarktheatres ticket confirmations, a local restaurant's email verification for signup, and some others along those lines). In fact, the split between obvious spam and no-spam seems to be about 80/20 with low hitrate either way. Yes, I know their mail servers are mis-configured put any PTR and HELO checks at the *bottom* of your restrictions and conigure the SPF check as well as much as possible DNSWL to skip them Hmm. I usually put cheap checks first me too, hence that all comes before milters Reading on SPF in postfix I see: http://www.postfix.org/SMTPD_ACCESS_README.html The greylisting and SPF policies are implemented externally, Which I thought was no longer true. # postconf -d | grep spf spf_explanation = spf_global_whitelist = no spf_local_policy = spf_mark_only = no spf_patch_version = 1.1.0 spf_received_header = yes spf_reject_code = 550 spf_reject_dsn = 5.7.1 that's a *not offical* postfix with discouraged pacthes I haven’t setup SPF in postfix, but those are the default setting. Searching postfix.org site for spf_local_policy returns no hits so I’ve not found the documentation on these settings. It may be on my computer. because it is not part of postfix as said above hence no real problems here while we update the checks automatically once per day by the current http://data.iana.org/TLD/tlds-alpha-by-domain.txt to not miss new TLD's and jeject any non-existing Well, .local is definitely a non-existing tld, and any mail server using that as it’s helo is badly broken. It used to be a 100% spam indicator for me, but now it is less so. that is all true but the problem is when some ordinary user sends business mail to a ordinary user on my side and we reject i get called and so i prefer to not need contacting every admin of a badly configured server - they are too much :-) frankly i have even a /^localhost\.localdomain$/ DUNNO on top for exactly the same reason /etc/python-policyd-spf/policyd-spf.conf Ah, I will ook at installing that package. Thanks that's my full config HELO_reject is disabled by intention after a false positive on the first day with the new system which was a order confirmation with a donwload-link, the default rejects even HELO-softfail cat /etc/python-policyd-spf/policyd-spf.conf debugLevel = 1 defaultSeedOnly = 1 HELO_reject = No_Check Mail_From_reject = Fail Mail_From_pass_restriction = OK PermError_reject = False TempError_Defer = True
Re: cannot send emails - NOQUEUE: reject: RCPT
Am 14.02.2015 um 22:34 schrieb Brad s: You should refrain from being so condescending if you would just do what people are telling you it's fixed. because of verbose logging pointing me to the error, slowly I weeded it down to a broken variable in relay_recipient_maps pretty sure with the non-verbose logging around the line of the subject NOQUEUE: reject: RCPT we would have been able to tell you that also So, you were looking in the wrong place. no i was not the next time when you write NOQUEUE: reject: RCPT in a subject paste the *uncutted* loglines around that one in the post instead bugger about 5 outgoing-only lines in https://bpaste.net/show/79c1ea5f65e6 that's where any expierienced mailadmin starts to look for troubles in combination with postconf -n and if you think you are smarter in debugging then do that alone, if you are asking for others help you have to provide the informations requested by them On Sat, Feb 14, 2015 at 2:35 PM, li...@rhsoft.net: Am 14.02.2015 um 20:29 schrieb Brad s: Here are your logs without verbose logging https://bpaste.net/show/__79c1ea5f65e6 https://bpaste.net/show/79c1ea5f65e6 Can see anything now. But you were very insistent forget it - i have no nicer words than you are not able to privide basic informations and hence should refrain to maintain servers because a) you repeatly post links instead inline informations and b) no default postfix logging would miss the smtpd lines so there are three options for the logging: * you posted (intentionally) a random snippet from the maillig * you misconfigured logging badly * your syslog daemon is broken or logging elsewehere than you look however, i am out of this useless thread because i refuse to waste my time with people not following basic instructions of the list welcome message
Re: helo_checks
Am 15.02.2015 um 00:02 schrieb LuKreme: that's a *not offical* postfix with discouraged pacthes Is it? dammit. I built with SYSLIBS = -L/usr/local/lib -lpcre -L/usr/local/lib -lsasl2 -lpam -lcrypt -L/usr/local/lib -Wl,-rpath,/usr/local/lib -lssl -lcrypto -L/usr/local/lib -lspf2 -L/usr/local/lib/db5 -ldb-5.3 -L/usr/local/lib/mysql -lmysqlclient -lz -lcrypt -lm -L/usr/local/lib -lldap -llber -L/usr/local/lib -lcdb Via portmaster. I guess -lspf2 is the not official and discouraged portion? yes - postfix don't know anything about SPF amd http://www.libspf2.org/patch/postfix-libspf2.README is 3rd party software see also Wietse's response after facing your output downstream maintainers really should learn to refrain from apply random patches to every software, especially the ones where the upstream developer says don't do that
Re: Local delivery continues after code 550
Am 13.02.2015 um 15:50 schrieb Mats Luspa: I have configured an outgoing server that relays one domain to a smtp-host and the rest of the addresses to the internet. I'm using the transport_maps-option and have no value on relayhost. The transport-map has the following information: irf.sesmtp:[mail.irf.se]:X * smtp: this is *not* local delivery this is *smtp* wildcard is *always* bad http://www.postfix.org/ADDRESS_VERIFICATION_README.html http://www.postfix.org/LOCAL_RECIPIENT_README.html http://www.postfix.org/LOCAL_RECIPIENT_README.html#main_config It works well for mail-addresses that exists. However when I send mail to a non-existing mail address it is only deferred when it should be rejected. I have checked the log files and it seems that my outgoing mail server gets the reject code 550 but continues to consider the non-existing mailaddress as a local mail address and tries to deliver it locally. When that not succeed it put the mail message into the deferred queue. The result is that it now continues to try to send that mail and the sending user gets Undeliverable-messages continuously. What configuration should be done to stop local delivery of a message after the server has gotten code 550 for that message? who knows when you don't provide postconnf -n and no logs while talk about local delivery but say above you are using smtp tramsports
Re: Message-Id header missing
Am 13.02.2015 um 16:23 schrieb Gianluca Gargiulo: can i tell to postfix forse add Message-Id header if is not present? you need to adjust local_header_rewrite_clients to your environment local_header_rewrite_clients = permit_mynetworks always_add_missing_headers = yes
Re: Message-Id header missing
Am 14.02.2015 um 01:50 schrieb Benny Pedersen: On 13. feb. 2015 16.23.55 Gianluca Gargiulo wrote: can i tell to postfix forse add Message-Id header if is not present? to get a better help, postconf -n is needed, since no one have crystall balls here WTF would anybody need postconf -n output for that pretty clear question with a simple answer already given multiple multiple times in that thread???
rpmbuild and shared=yes
has somebody an idea for the chicken egg problem that postfix-install
in the %installof a RPM-spec can't load the shared libraries which are
built but not installed at that moment?
+ sh postfix-install -non-interactive
install_root=/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-1.fc21.20150212.rh.x86_64
config_directory=/etc/postfix meta_directory=/usr/libexec/postfix
daemon_directory=/usr/libexec/postfix command_directory=/usr/sbin
queue_directory=/var/spool/postfix data_directory=/var/lib/postfix
sendmail_path=/usr/sbin/sendmail newaliases_path=/usr/bin/newaliases
mailq_path=/usr/bin/mailq mail_owner=postfix setgid_group=postdrop
manpage_directory=/usr/share/man
sample_directory=/usr/share/doc/postfix-3.0.0/samples
readme_directory=/usr/share/doc/postfix-3.0.0/README_FILES
bin/postconf: error while loading shared libraries:
libpostfix-global.so: cannot open shared object file: No such file or
directory
bin/postconf: error while loading shared libraries:
libpostfix-global.so: cannot open shared object file: No such file or
directory
_
%build
CCARGS=-fPIC -DNO_NIS -DNO_NISPLUS -DNO_EAI -DNO_LMDB -DNO_CDB
-DNO_LDAP -DNO_PGSQL -DNO_SQLITE -DHAS_PCRE -I%{_includedir}/pcre
-DHAS_MYSQL -I%{_includedir}/mysql -DUSE_TLS -DUSE_SASL_AUTH
-DUSE_CYRUS_SASL -I%{_includedir}/sasl
-DDEF_CONFIG_DIR=\\\%{postfix_config_dir}\\\
-DDEF_META_DIR=\\\%{postfix_daemon_dir}\\\
AUXLIBS=-lpcre -L%{_libdir}/mysql -lmysqlclient -lm -L%{_libdir}/sasl2
-lsasl2 -lssl -lcrypto -Wl,-z,now -Wl,-z,relro,-z,noexecstack
%{__make} %{?_smp_mflags} -f Makefile.init makefiles shared=yes
CCARGS=${CCARGS} AUXLIBS=${AUXLIBS} DEBUG= OPT=%{optflags}
-Wno-comment -fno-strict-aliasing
%{__make} %{?_smp_mflags} CCARGS=${CCARGS} AUXLIBS=${AUXLIBS}
DEBUG= OPT=%{optflags} -Wno-comment -fno-strict-aliasing
%install
sh postfix-install -non-interactive install_root=%{buildroot}
config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
install -c auxiliary/rmail/rmail %{buildroot}%{_bindir}/rmail
Re: rpmbuild and shared=yes
well, set LD_LIBRARY_PATH does the trick
shoudn't postfix-install do that on it's own?
%install
LD_LIBRARY_PATH=$(pwd)/lib sh postfix-install -package -non-interactive
install_root=%{buildroot} config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
shlib_directory=%{postfix_shlib_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
Am 12.02.2015 um 11:20 schrieb li...@rhsoft.net:
has somebody an idea for the chicken egg problem that postfix-install
in the %installof a RPM-spec can't load the shared libraries which are
built but not installed at that moment?
+ sh postfix-install -non-interactive
install_root=/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-1.fc21.20150212.rh.x86_64
config_directory=/etc/postfix meta_directory=/usr/libexec/postfix
daemon_directory=/usr/libexec/postfix command_directory=/usr/sbin
queue_directory=/var/spool/postfix data_directory=/var/lib/postfix
sendmail_path=/usr/sbin/sendmail newaliases_path=/usr/bin/newaliases
mailq_path=/usr/bin/mailq mail_owner=postfix setgid_group=postdrop
manpage_directory=/usr/share/man
sample_directory=/usr/share/doc/postfix-3.0.0/samples
readme_directory=/usr/share/doc/postfix-3.0.0/README_FILES
bin/postconf: error while loading shared libraries:
libpostfix-global.so: cannot open shared object file: No such file or
directory
bin/postconf: error while loading shared libraries:
libpostfix-global.so: cannot open shared object file: No such file or
directory
_
%build
CCARGS=-fPIC -DNO_NIS -DNO_NISPLUS -DNO_EAI -DNO_LMDB -DNO_CDB
-DNO_LDAP -DNO_PGSQL -DNO_SQLITE -DHAS_PCRE -I%{_includedir}/pcre
-DHAS_MYSQL -I%{_includedir}/mysql -DUSE_TLS -DUSE_SASL_AUTH
-DUSE_CYRUS_SASL -I%{_includedir}/sasl
-DDEF_CONFIG_DIR=\\\%{postfix_config_dir}\\\
-DDEF_META_DIR=\\\%{postfix_daemon_dir}\\\
AUXLIBS=-lpcre -L%{_libdir}/mysql -lmysqlclient -lm -L%{_libdir}/sasl2
-lsasl2 -lssl -lcrypto -Wl,-z,now -Wl,-z,relro,-z,noexecstack
%{__make} %{?_smp_mflags} -f Makefile.init makefiles shared=yes
CCARGS=${CCARGS} AUXLIBS=${AUXLIBS} DEBUG= OPT=%{optflags}
-Wno-comment -fno-strict-aliasing
%{__make} %{?_smp_mflags} CCARGS=${CCARGS} AUXLIBS=${AUXLIBS}
DEBUG= OPT=%{optflags} -Wno-comment -fno-strict-aliasing
%install
sh postfix-install -non-interactive install_root=%{buildroot}
config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
install -c auxiliary/rmail/rmail %{buildroot}%{_bindir}/rmail
Re: spamass-milter
Am 12.02.2015 um 23:56 schrieb LuKreme: On 12 Feb 2015, at 13:42 , Noel Jones njo...@megan.vbhcs.org wrote: spamass-milter uses the standard spamassassin spamc/spamd interface. I believe you can enable additional spamass-milter logging on its startup command line. There are startup flags you can add to spamass-milter to reject mail over a certain score. I’m guessing that setting a reject flag would require that I also change the value of milter_default_action from accept to tempfail? If I’m reading the docs right, accept will pass the mail on for delivery regardless of the milter? why would you touch that? that is not at accept at all as default postconf -d milter_default_action milter_default_action = tempfail that applies when the milter is not reachable to answer with a 450, that has nothing to do with a explicit REJECT repsone from the milter spamass-milter don't need anything else than the correct start params and hence it don't parse anything here but is a template for the systemd-unit feeded from a database and the cronjob fires up the systemd-reload before the restart command ExecStart=/usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r [required_hits_reject] -- -s [max_msg_size] --port=10028
Re: spamass-milter
Am 12.02.2015 um 21:26 schrieb LuKreme: I believe I have the spams-milter working with postfix main.cf milter_default_action = accept smtpd_milters = unix:/var/run/spamass-milter.sock Two questions. Wouldn’t the log show the milter instead of spamd? no And now that this is working, how do I reject incoming messages based on their score (for example, say I wanted to reject all spam scoring 9.0 or higher)? /usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8.0 -- -s 5242880 --port=10028 the -r 8.0 is the reject score params after -- are for spamd technically the milter becomes back the modified message and parses the score header for the decision
Re: rpmbuild and shared=yes
Am 12.02.2015 um 15:32 schrieb Wietse Venema:
Wietse Venema:
li...@rhsoft.net:
[ Charset windows-1252 converted... ]
Am 12.02.2015 um 14:12 schrieb Wietse Venema:
li...@rhsoft.net:
well, set LD_LIBRARY_PATH does the trick
shoudn't postfix-install do that on it's own?
You MUST NOT invoke postfix-install directly.
You MUST use make install as described in the INSTALL instructions
besides that SPEC is derived from Redhat ones years ago using make
install seems to change the whole semantic of what is happening in the
%install section
Instead of sh postfix-install name=value use make install name=value
i did that as you can see on bottom if the message you responded to
make install -non-interactive install_root=%{buildroot}
config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
shlib_directory=%{postfix_shlib_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
Re: rpmbuild and shared=yes
Am 12.02.2015 um 14:12 schrieb Wietse Venema:
li...@rhsoft.net:
well, set LD_LIBRARY_PATH does the trick
shoudn't postfix-install do that on it's own?
You MUST NOT invoke postfix-install directly.
You MUST use make install as described in the INSTALL instructions
besides that SPEC is derived from Redhat ones years ago using make
install seems to change the whole semantic of what is happening in the
%install section
there is *nothing* but empty folders - so where does it install to?
also tried with make install DESTDIR=%{buildroot} -non-interactive
___
looks like postfix-install is *not* called with all the makro-params
LD_LIBRARY_PATH=/home/builduser/rpmbuild/BUILD/postfix-3.0.0/lib
shlib_directory=${shlib_directory:-`LD_LIBRARY_PATH=/home/builduser/rpmbuild/BUILD/postfix-3.0.0/lib
bin/postconf -dhx shlib_directory`} /bin/sh postfix-install
*these* are important for the package building process:
-package -non-interactive install_root=%{buildroot}
config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
shlib_directory=%{postfix_shlib_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir}
___
[builduser@testserver:/rpmbuild/SPECS]$ ls -R
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/:
total 12K
drwxr-xr-x 3 builduser builduser 4.0K 2015-02-12 14:26 etc
drwxr-xr-x 4 builduser builduser 4.0K 2015-02-12 14:26 usr
drwxr-xr-x 3 builduser builduser 4.0K 2015-02-12 14:26 var
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/etc:
total 4.0K
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 pam.d
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/etc/pam.d:
total 4.0K
-rw-r--r-- 1 builduser builduser 76 2015-02-12 14:26 smtp.postfix
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/usr:
total 8.0K
drwxr-xr-x 3 builduser builduser 4.0K 2015-02-12 14:26 lib64
drwxr-xr-x 3 builduser builduser 4.0K 2015-02-12 14:26 share
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/usr/lib64:
total 4.0K
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 postfix
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/usr/lib64/postfix:
total 0
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/usr/share:
total 4.0K
drwxr-xr-x 3 builduser builduser 4.0K 2015-02-12 14:26 doc
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/usr/share/doc:
total 4.0K
drwxr-xr-x 3 builduser builduser 4.0K 2015-02-12 14:26 postfix-3.0.0
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/usr/share/doc/postfix-3.0.0:
total 4.0K
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 examples
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/usr/share/doc/postfix-3.0.0/examples:
total 0
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/var:
total 4.0K
drwxr-xr-x 3 builduser builduser 4.0K 2015-02-12 14:26 spool
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/var/spool:
total 4.0K
drwxr-xr-x 15 builduser builduser 4.0K 2015-02-12 14:26 postfix
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/var/spool/postfix:
total 52K
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 active
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 bounce
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 corrupt
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 defer
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 deferred
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 flush
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 incoming
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 maildrop
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 pid
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 private
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 public
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 saved
drwxr-xr-x 2 builduser builduser 4.0K 2015-02-12 14:26 trace
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/var/spool/postfix/active:
total 0
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4.fc21.20150212.rh.x86_64/var/spool/postfix/bounce:
total 0
/home/builduser/rpmbuild/BUILDROOT/postfix-3.0.0-4
Re: rpmbuild and shared=yes
Am 12.02.2015 um 17:13 schrieb Viktor Dukhovni:
On Thu, Feb 12, 2015 at 04:58:39PM +0100, li...@rhsoft.net wrote:
that below works like a charm:
make non-interactive-package install_root=%{buildroot}
config_directory=%{postfix_config_dir} meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir} shlib_directory=%{postfix_shlib_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
After this installs the bits Postfix always installs (that are
listed in the stock postfix-files):
* If you're building with dynamicmaps=yes and want to create
separate packages for the various database drivers, then
consider creating a per-driver .cf file in:
$meta_directory/dynamicmaps.cf.d/
listing just that table type and corresponding module path.
plus whatever logic you'll need to deliver the plugin module
and the corresponding dynamicmaps config snippet as a separate
package.
* If you want to install optional test bits:
posttls-finger, smtp-sink, smtp-source, ...
You'll have to copy those in yourself, and add them to postfix-files
or postfix-files.d/sub-package as appropriate
thanks for the hint, only everywhere used libraries are linked
the reason for shared=yes was more to get the single postfix binaries
smaller and using shared libraries for optimized memory usage
well, the manpages are already in a subpackage only installed on the
admin-machine instead everywhere
%files manpages
%{postfix_doc_dir}
%attr(0644, root, root) %{_mandir}/man1/*
%attr(0644, root, root) %{_mandir}/man5/*
%attr(0644, root, root) %{_mandir}/man8/*
Re: rpmbuild and shared=yes
Am 12.02.2015 um 17:18 schrieb Wietse Venema: li...@rhsoft.net: Am 12.02.2015 um 17:08 schrieb Wietse Venema: li...@rhsoft.net: according to the subject a You MUST use make non-interactive-package would have saved a lot of noise including the completly unnecessary flames about rpm crap without *by all respect* no clue about how it works and that the macros are replaced before any bit of postfix source could face them I provide the interfaces. It is your job to choose the right one. not when you say You MUST use THAT because if i try to mangle that because it just don't work you would repsond did i say this and that? Without a clear statement what you want (build installable package) I have to guess that you want to install Postfix. The supported interface is make whatever. People who grope under that interface are lucky if I provide any support at all. can we stop that discussion and both admit that we handeled the issue not really good? Without a clear statement what you want when the subject begins with rpmbuild? seriously? :-)
Re: rpmbuild and shared=yes
Am 12.02.2015 um 15:50 schrieb Wietse Venema:
li...@rhsoft.net:
Instead of sh postfix-install name=value use make install name=value
i did that as you can see on bottom if the message you responded to
make install -non-interactive install_root=%{buildroot}
config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
shlib_directory=%{postfix_shlib_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
No, I said:
make install name=value
without rpmbuild crap. I support make install only. I do not support
rcpmbuild crap.
interesting attitude in context of subject rpmbuild and shared=yes
I want you to execute the command without rpmbuild crap, and if
that command without rpmbuild crap does not work, then I will try
to find out why that command without rpmbuild crap does not work.
%{whatever} is replaced by the makros defined on top of the SPEC to
write paths just once and re-use them, they are simply replaced
frankly for any other package you use make install
DESTDIR=%{buildroot} which installs the already compiled binaries in
buildroot and that's it, the paths are defined by ./configure
Re: rpmbuild and shared=yes
the most likely reason is make install versus make upgrade which
*both* don't apply for a rpmbuild because there is no business for
interactive and no business for non-interactive version, for upgrades
would make install just work non-interactive problem gone
# make install (interactive version, first time install)
# make upgrade (non-interactive version, for upgrades)
pretty sure the reason why Redhat is using postfix-install while for
all other packages make install DESTDIR=%{buildroot} is in use
Am 12.02.2015 um 16:00 schrieb li...@rhsoft.net:
Am 12.02.2015 um 15:50 schrieb Wietse Venema:
li...@rhsoft.net:
Instead of sh postfix-install name=value use make install
name=value
i did that as you can see on bottom if the message you responded to
make install -non-interactive install_root=%{buildroot}
config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
shlib_directory=%{postfix_shlib_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
No, I said:
make install name=value
without rpmbuild crap. I support make install only. I do not support
rcpmbuild crap.
interesting attitude in context of subject rpmbuild and shared=yes
I want you to execute the command without rpmbuild crap, and if
that command without rpmbuild crap does not work, then I will try
to find out why that command without rpmbuild crap does not work.
%{whatever} is replaced by the makros defined on top of the SPEC to
write paths just once and re-use them, they are simply replaced
frankly for any other package you use make install
DESTDIR=%{buildroot} which installs the already compiled binaries in
buildroot and that's it, the paths are defined by ./configure
Re: rpmbuild and shared=yes
Am 12.02.2015 um 16:10 schrieb Wietse Venema:
li...@rhsoft.net:
No, I said:
make install name=value
without rpmbuild crap. I support make install only. I do not support
rcpmbuild crap.
interesting attitude in context of subject rpmbuild and shared=yes
Please stick to the supported interfaces:
make makefiles name=value...
make
make install name=value...
make upgrade name=value...
etcetera
Where is your make command without rpmbuild crap? I am willing
to provide support at that level. I do not provide support at the
level of RedHat, Debian, Solaris, *BSD, or Apple package managers
the *real problem* is that make install is *interactive* and the
non-interactive make upgrade can't work at all while make install
-non-interactive talks about nothing to do for update
config_directory=%{postfix_config_dir} is *notging else* than
config_directory=/etc/postfix and i replaced *long before* make
install will be called
the whole purpose of a rpmbuild is to install into an *always empty*
tree as ordinary user and after that pack that tree with all folders,
files and permissions into an archive
Re: rpmbuild and shared=yes
Am 12.02.2015 um 16:21 schrieb Wietse Venema:
li...@rhsoft.net:
the most likely reason is make install versus make upgrade which
*both* don't apply for a rpmbuild because there is no business for
interactive and no business for non-interactive version, for upgrades
would make install just work non-interactive problem gone
# make install (interactive version, first time install)
# make upgrade (non-interactive version, for upgrades)
The only difference between install and upgrade is that one is
interactive and the other is not. That is, install is an upgrade
from zero with all the answers pre-determined
make install -non-interactive simply ends in *nothing* installed into
the build-tree nor somewhere else
make: Nothing to be done for 'update'.
[src/fsstone]
make: Nothing to be done for 'update'.
[src/smtpstone]
make: Nothing to be done for 'update'.
[src/sendmail]
make: Nothing to be done for 'update'.
[src/error]
make: Nothing to be done for 'update'.
[src/pickup]
make: Nothing to be done for 'update'.
[src/cleanup]
make: Nothing to be done for 'update'.
[src/smtpd]
make: Nothing to be done for 'update'.
[src/local]
make: Nothing to be done for 'update'.
[src/trivial-rewrite]
make: Nothing to be done for 'update'.
[src/qmgr]
make: Nothing to be done for 'update'.
[src/oqmgr]
make: Nothing to be done for 'update'.
[src/smtp]
make: Nothing to be done for 'update'.
[src/bounce]
make: Nothing to be done for 'update'.
[src/pipe]
make: Nothing to be done for 'update'.
[src/showq]
make: Nothing to be done for 'update'.
[src/postalias]
make: Nothing to be done for 'update'.
[src/postcat]
make: Nothing to be done for 'update'.
[src/postconf]
make: Nothing to be done for 'update'.
[src/postdrop]
make: Nothing to be done for 'update'.
[src/postkick]
make: Nothing to be done for 'update'.
[src/postlock]
make: Nothing to be done for 'update'.
[src/postlog]
make: Nothing to be done for 'update'.
[src/postmap]
make: Nothing to be done for 'update'.
[src/postqueue]
make: Nothing to be done for 'update'.
[src/postsuper]
make: Nothing to be done for 'update'.
[src/qmqpd]
make: Nothing to be done for 'update'.
[src/spawn]
make: Nothing to be done for 'update'.
[src/flush]
make: Nothing to be done for 'update'.
[src/verify]
make: Nothing to be done for 'update'.
[src/virtual]
make: Nothing to be done for 'update'.
[src/proxymap]
make: Nothing to be done for 'update'.
[src/anvil]
make: Nothing to be done for 'update'.
[src/scache]
make: Nothing to be done for 'update'.
[src/discard]
make: Nothing to be done for 'update'.
[src/tlsmgr]
make: Nothing to be done for 'update'.
[src/postmulti]
make: Nothing to be done for 'update'.
[src/postscreen]
make: Nothing to be done for 'update'.
[src/dnsblog]
make: Nothing to be done for 'update'.
[src/tlsproxy]
make: Nothing to be done for 'update'.
[src/posttls-finger]
make: Nothing to be done for 'update'.
LD_LIBRARY_PATH=/home/builduser/rpmbuild/BUILD/postfix-3.0.0/lib
shlib_directory=${shlib_directory:-`LD_LIBRARY_PATH=/home/builduser/rpmbuild/BUILD/postfix-3.0.0/lib
bin/postconf -dhx shlib_directory`} /bin/sh \
postfix-install
Re: rpmbuild and shared=yes
Am 12.02.2015 um 16:43 schrieb Viktor Dukhovni:
On Thu, Feb 12, 2015 at 10:40:47AM -0500, Wietse Venema wrote:
Where did I tell you to make install -non-interactive?
As I explained above, use make upgrade you want a non-interactive
install.
I believe he does not want an install (directly to the final
locations), he wants a package build, therefore as per my other
email
thank you!
according to the subject a You MUST use make non-interactive-package
would have saved a lot of noise including the completly unnecessary
flames about rpm crap without *by all respect* no clue about how it
works and that the macros are replaced before any bit of postfix source
could face them
that below works like a charm:
make non-interactive-package install_root=%{buildroot}
config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
shlib_directory=%{postfix_shlib_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
now it's also clear from where the postfix-install call is coming and
since it worked for many years and also 3.0 without shared, well..
With Postfix versions before 2.2 you must invoke the post-install script
directly (% sh post-install -non-interactive install_root...)
Re: rpmbuild and shared=yes
Am 12.02.2015 um 17:01 schrieb Wietse Venema: Viktor Dukhovni: On Thu, Feb 12, 2015 at 10:40:47AM -0500, Wietse Venema wrote: Where did I tell you to make install -non-interactive? As I explained above, use make upgrade you want a non-interactive install. I believe he does not want an install (directly to the final locations), he wants a package build, therefore as per my other email. And this is supported as well. I can provide the necessary interfaces (lead the horse to the water) but I can't force people to use them (drink the water) that is all true - but you could give the correct answer or none when somebody posts the *working* solution he found out by himself instead a wrong one with a big fat You MUST use - your repsone below was wrong and leaded to all the other try around and ping pong frankly *i had the build running* and so answered my own question with the intention others with the same problems can find that information later and got corrected with non working instructions that is not helpful Weitergeleitete Nachricht Betreff: Re: rpmbuild and shared=yes Datum: Thu, 12 Feb 2015 08:12:44 -0500 (EST) Von: Wietse Venema wie...@porcupine.org An: li...@rhsoft.net li...@rhsoft.net Kopie (CC): postfix-users@postfix.org li...@rhsoft.net: well, set LD_LIBRARY_PATH does the trick shoudn't postfix-install do that on it's own? You MUST NOT invoke postfix-install directly. You MUST use make install as described in the INSTALL instructions.
Re: rpmbuild and shared=yes
Am 12.02.2015 um 17:08 schrieb Wietse Venema: li...@rhsoft.net: according to the subject a You MUST use make non-interactive-package would have saved a lot of noise including the completly unnecessary flames about rpm crap without *by all respect* no clue about how it works and that the macros are replaced before any bit of postfix source could face them I provide the interfaces. It is your job to choose the right one. not when you say You MUST use THAT because if i try to mangle that because it just don't work you would repsond did i say this and that?
Re: rpmbuild and shared=yes
Am 12.02.2015 um 17:33 schrieb Wietse Venema:
li...@rhsoft.net:
Am 12.02.2015 um 17:18 schrieb Wietse Venema:
li...@rhsoft.net:
Am 12.02.2015 um 17:08 schrieb Wietse Venema:
li...@rhsoft.net:
according to the subject a You MUST use make non-interactive-package
would have saved a lot of noise including the completly unnecessary
flames about rpm crap without *by all respect* no clue about how it
works and that the macros are replaced before any bit of postfix source
could face them
I provide the interfaces. It is your job to choose the right one.
not when you say You MUST use THAT because if i try to mangle that
because it just don't work you would repsond did i say this and that?
Without a clear statement what you want (build installable package)
I have to guess that you want to install Postfix. The supported
interface is make whatever. People who grope under that interface
are lucky if I provide any support at all.
can we stop that discussion and both admit that we handeled the issue
not really good? Without a clear statement what you want when the
subject begins with rpmbuild? seriously? :-)
You are like people who ask I use Sendmail or qmail or Exim feature
X, how do I do that with Postfix?, without a clear statement of
what X does. I am not interested in how rpmbuild works.
well, you are not able to admit a mistake, so be it
Without a clear statement what you want (build installable package) is
ridiculous because rpmbuild is an as clear as possible statement that
the goal is build installable package as well you do not need to be
interested in how rpmbuild works
but than you should not insist in remove the crap of macros while the
person on the other side is knowing how it works and that there is no
technical differene between something=/path/ or something=%{path_macro}
besides you have to type that only once on top, reuse it in the rest of
the file and if you change a value it's consistent everywhere
Re: Postscreen rejecting with 450, on postfix restart, gets immediately through
Am 11.02.2015 um 23:14 schrieb Shawn Heisey: Currently my production mail relay for work (sitting between Exchange and the Internet) uses Postfix 2.9.3 on Debian 6. I'm building up a new system using Postfix 2.11.0 on Ubuntu 14, and incorporating postscreen as the first line of defense. Almost all the software is installed with distro packages in both cases. The postscreen config is based on rob0's example that is available on the Internet. After the server has been running for a while, it will reject all connection attempts with a 450 code. There's nothing in the log as to why it's being rejected just don't enable deep protocol tests if you don't want 450 rejects and rob0's example is nice but don't blindly follow howtos without real understanding http://www.postfix.org/POSTSCREEN_README.html http://www.postfix.org/POSTSCREEN_README.html#after_220 just don't enable that without good consideration safe: postscreen_dnsbl_action = enforce postscreen_greet_action = enforce to handle with care and hence disabled here: # deep protocol tests postscreen_bare_newline_enable = no postscreen_bare_newline_action = enforce postscreen_pipelining_enable = no postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = no postscreen_non_smtp_command_action = enforce
Re: Postscreen rejecting with 450, on postfix restart, gets immediately through
Am 12.02.2015 um 01:03 schrieb Shawn Heisey: On 2/11/2015 3:24 PM, li...@rhsoft.net wrote: just don't enable deep protocol tests if you don't want 450 rejects and rob0's example is nice but don't blindly follow howtos without real understanding http://www.postfix.org/POSTSCREEN_README.html http://www.postfix.org/POSTSCREEN_README.html#after_220 I did look at that README, but apparently I did not fully grasp what I was reading. Thanks for the prod in the right direction. Is there any way to enable some logging so that I can definitively tell which part of the postscreen config is responsible for a rejection, without enabling extremely verbose logging? no, but there are only two reasons for a 450 reject in postscreen * a enabled deep protocol test * postscreen_whitelist_interfaces = !honeypot-backup-mx-ip, static:all On my re-read of the README, if I'm understanding it right, the options I have chosen will result in an automatic reject of all connections from a new source. When they retry, they will be allowed through, if they passed the tests and the reconnect is within the time limit. To test this theory, I deleted the postscreen_cache.db file, restarted, and tried a new message. The first attempt was rejected with the 450, but when I flushed the queue on the sender immediately without restarting postfix on the receiver, the message cleared postscreen successfully. This is a little bit like a greylist. it is in fact and it may lead to all the troubles of greylisting for mails from large senders spread temporary undeliverable mail to different nodes and so never reach the whitelisting hence the idea of the postscreen_whitelist_interfaces is way better because it mainly affects bots trying the backup-mx first and never come back and don't harm senders re-try on the primary MX I'm planning to increase postscreen_dnsbl_ttl to 4 hours. Does this set off any red flags for anyone? depends on your spam-flow i would consider it way too long because it caches also NXDOMAIN results of spambots not in enough blacklists now but make it there within the TTL timeframe
Re: Postfix stable release 3.0.0
Am 08.02.2015 um 23:29 schrieb Wietse Venema: [An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-3.0.0.html] Postfix stable release 3.0.0 is available. This release ends support for Postfix 2.8 thanks - especially for the header_checks BCC feature! one question: why are postfix-files, main.cf.proto and master.cf.proto below /etc since they are not intended to get modified by the admin and hence belongs somewhere below /usr? files below /etc are typically packaged as %config(noreplace) which would be definitly wrong in that case
Re: Postfix stable release 3.0.0
Am 09.02.2015 um 20:32 schrieb Viktor Dukhovni:
On Mon, Feb 09, 2015 at 08:22:12PM +0100, li...@rhsoft.net wrote:
I don't set meta_directory to
/etc in my builds. Indeed none of the meta_directory files are
intended to be configuration files that are hand-edited. They
should only be modified as a side-effect of package installation
or removal. This includes dynamicmaps.cf{,.d}, which list installed
dictionary plugins.
well, looks like $meta_directory defaults to /etc, at least *that* is where
they ended in my rpmbuild just change the tarball
Yes, perhaps as a concession to compatibility with Debian, but feel
free to use a more suitable location
well, meta_directory=%{postfix_daemon_dir} at build leads in
/usr/libexec/postfix/postfix-files instead /etc/postfix/postfix-files
but postfix refuses to start like below
cp /usr/libexec/postfix/postfix-files /etc/postfix/postfix-files
and all is fine - so it seems to expect that file somehow below /etc/postfix
Feb 9 21:31:57 testserver postfix/postfix-script[3378]: waiting for the
Postfix mail system to terminate
Feb 9 21:31:59 testserver postfix/postfix-script[3404]: fatal: unable
to create missing queue directories
Feb 9 21:31:59 testserver postfix/postfix-script[3405]: fatal: Postfix
integrity check failed!
Feb 9 21:32:00 testserver postfix/postfix-script[3426]: fatal: unable
to create missing queue directories
Feb 9 21:32:00 testserver postfix/postfix-script[3427]: fatal: Postfix
integrity check failed!
Feb 9 21:32:01 testserver postfix/postfix-script[3448]: fatal: unable
to create missing queue directories
Feb 9 21:32:01 testserver postfix/postfix-script[3449]: fatal: Postfix
integrity check failed!
Feb 9 21:32:02 testserver postfix/postfix-script[3473]: fatal: unable
to create missing queue directories
Feb 9 21:32:02 testserver postfix/postfix-script[3474]: fatal: Postfix
integrity check failed!
Feb 9 21:32:04 testserver postfix/postfix-script[3495]: fatal: unable
to create missing queue directories
Feb 9 21:32:04 testserver postfix/postfix-script[3496]: fatal: Postfix
integrity check failed!
Re: Postfix stable release 3.0.0
Am 09.02.2015 um 21:51 schrieb li...@rhsoft.net:
Am 09.02.2015 um 21:46 schrieb Wietse Venema:
li...@rhsoft.net:
well, meta_directory=%{postfix_daemon_dir} at build leads in
/usr/libexec/postfix/postfix-files instead /etc/postfix/postfix-files
but postfix refuses to start like below
cp /usr/libexec/postfix/postfix-files /etc/postfix/postfix-files
Please do a proper install without copying files by hand
*i do*
that was only to demonstrate that it still seeks it in /etc
the problem is that built-in meta_directory defaults to /etc/postfix
[root@testserver:~]$ postconf -d meta_directory
meta_directory = /etc/postfix
ok, add -DDEF_META_DIR to CCARGS changes the default
issue solved, postfix 3.0 is running perfectly - thanks!
CCARGS=-fPIC -DNO_NIS -DNO_NISPLUS -DNO_EAI -DNO_LMDB -DNO_CDB
-DNO_LDAP -DNO_PGSQL -DNO_SQLITE -DHAS_PCRE -I%{_includedir}/pcre
-DHAS_MYSQL -I%{_includedir}/mysql -DUSE_TLS -DUSE_SASL_AUTH
-DUSE_CYRUS_SASL -I%{_includedir}/sasl
-DDEF_CONFIG_DIR=\\\%{postfix_config_dir}\\\
-DDEF_META_DIR=\\\%{postfix_daemon_dir}\\\
[root@testserver:~]$ postconf -d meta_directory
meta_directory = /usr/libexec/postfix
Re: Postfix stable release 3.0.0
Am 09.02.2015 um 21:46 schrieb Wietse Venema:
li...@rhsoft.net:
well, meta_directory=%{postfix_daemon_dir} at build leads in
/usr/libexec/postfix/postfix-files instead /etc/postfix/postfix-files
but postfix refuses to start like below
cp /usr/libexec/postfix/postfix-files /etc/postfix/postfix-files
Please do a proper install without copying files by hand
*i do*
that was only to demonstrate that it still seeks it in /etc
the problem is that built-in meta_directory defaults to /etc/postfix
[root@testserver:~]$ postconf -d meta_directory
meta_directory = /etc/postfix
hence for now mv %{buildroot}%{postfix_daemon_dir}/postfix-files
%{buildroot}%{_sysconfdir}/%{name}/postfix-files after sh postfix-install
__
%build
CCARGS=-fPIC -DNO_NIS -DNO_NISPLUS -DNO_EAI -DNO_LMDB -DNO_CDB
-DNO_LDAP -DNO_PGSQL -DNO_SQLITE -DHAS_PCRE -I%{_includedir}/pcre
-DHAS_MYSQL -I%{_includedir}/mysql -DUSE_TLS -DUSE_SASL_AUTH
-DUSE_CYRUS_SASL -I%{_includedir}/sasl
-DDEF_CONFIG_DIR=\\\%{postfix_config_dir}\\\
AUXLIBS=-lpcre -L%{_libdir}/mysql -lmysqlclient -lm -L%{_libdir}/sasl2
-lsasl2 -lssl -lcrypto -pie -Wl,-z,now -Wl,-z,relro,-z,noexecstack
%{__make} %{?_smp_mflags} -f Makefile.init makefiles shared=no
CCARGS=${CCARGS} AUXLIBS=${AUXLIBS} DEBUG= OPT=%{optflags}
-Wno-comment -fno-strict-aliasing
%{__make} %{?_smp_mflags} CCARGS=${CCARGS} AUXLIBS=${AUXLIBS}
DEBUG= OPT=%{optflags} -Wno-comment -fno-strict-aliasing
%install
sh postfix-install -non-interactive install_root=%{buildroot}
config_directory=%{postfix_config_dir}
meta_directory=%{postfix_daemon_dir}
daemon_directory=%{postfix_daemon_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
install -c auxiliary/rmail/rmail %{buildroot}%{_bindir}/rmail
for i in active bounce corrupt defer deferred flush incoming private
saved maildrop public pid saved trace; do
mkdir -p %{buildroot}%{postfix_queue_dir}/$i
done
mkdir -p %{buildroot}%{_sysconfdir}/pam.d %{buildroot}%{postfix_doc_dir}
%{buildroot}%{postfix_doc_dir}/examples{,/chroot-setup}
install -m 644 %{SOURCE2} %{buildroot}%{_sysconfdir}/pam.d/smtp.%{name}
cp -pr examples/{qmail-local,smtpd-policy}
%{buildroot}%{postfix_doc_dir}/examples
cp -p examples/chroot-setup/LINUX2
%{buildroot}%{postfix_doc_dir}/examples/chroot-setup
rm -f %{buildroot}%{postfix_config_dir}/{TLS_,}LICENSE
%{buildroot}%{_sysconfdir}/%{name}/bounce.cf.default
%{buildroot}%{_sysconfdir}/%{name}/main.cf.default
mv %{buildroot}%{postfix_daemon_dir}/postfix-files
%{buildroot}%{_sysconfdir}/%{name}/postfix-files
find %{buildroot}%{postfix_doc_dir} -type f | xargs chmod 644
find %{buildroot}%{postfix_doc_dir} -type d | xargs chmod 755
Re: Postfix stable release 3.0.0
Am 09.02.2015 um 20:13 schrieb Viktor Dukhovni:
On Mon, Feb 09, 2015 at 07:47:50PM +0100, li...@rhsoft.net wrote:
one question:
why are postfix-files, main.cf.proto and master.cf.proto below /etc
since they are not intended to get modified by the admin and hence belongs
somewhere below /usr?
They are not in /etc:
$ egrep '(master|main|dynamicmaps)\.cf|postfix-files' conf/postfix-files
| egrep -v '^#' | sort
$config_directory/main.cf.default:f:root:-:644:1
$config_directory/main.cf:f:root:-:644:p
$config_directory/master.cf:f:root:-:644:p
$daemon_directory/main.cf:f:root:-:644:o
$daemon_directory/master.cf:f:root:-:644:o
$meta_directory/dynamicmaps.cf.d:d:root:-:755
$meta_directory/dynamicmaps.cf:f:root:-:644
$meta_directory/main.cf.proto:f:root:-:644
$meta_directory/master.cf.proto:f:root:-:644
$meta_directory/postfix-files.d:d:root:-:755
$meta_directory/postfix-files:f:root:-:644
Rather they are in $meta_directory. I don't set meta_directory to
/etc in my builds. Indeed none of the meta_directory files are
intended to be configuration files that are hand-edited. They
should only be modified as a side-effect of package installation
are removal. This includes dynamicmaps.cf{,.d}, which list installed
dictionary plugins.
well, looks like $meta_directory defaults to /etc, at least *that* is
where they ended in my rpmbuild just change the tarball
[harry@srv-rhsoft:~]$ postconf -d | grep meta
meta_directory = /etc/postfix
http://www.postfix.org/postconf.5.html#meta_directory
For backwards compatibility with Postfix versions 2.6..2.11, specify
meta_directory = $daemon_directory in main.cf before installing or
upgrading Postfix, or specify meta_directory = /path/name on the make
makefiles, make install or make upgrade command line
IMHO that should default to $daemon_directory
%build
CCARGS=-fPIC -DNO_NIS -DNO_NISPLUS -DNO_EAI -DNO_LMDB -DNO_CDB
-DNO_LDAP -DNO_PGSQL -DNO_SQLITE -DHAS_PCRE -I%{_includedir}/pcre
-DHAS_MYSQL -I%{_includedir}/mysql -DUSE_TLS -DUSE_SASL_AUTH
-DUSE_CYRUS_SASL -I%{_includedir}/sasl
-DDEF_CONFIG_DIR=\\\%{postfix_config_dir}\\\
AUXLIBS=-lpcre -L%{_libdir}/mysql -lmysqlclient -lm -L%{_libdir}/sasl2
-lsasl2 -lssl -lcrypto -pie -Wl,-z,now -Wl,-z,relro,-z,noexecstack
%{__make} %{?_smp_mflags} -f Makefile.init makefiles shared=no
CCARGS=${CCARGS} AUXLIBS=${AUXLIBS} DEBUG= OPT=%{optflags}
-Wno-comment -fno-strict-aliasing
%{__make} %{?_smp_mflags} CCARGS=${CCARGS} AUXLIBS=${AUXLIBS}
DEBUG= OPT=%{optflags} -Wno-comment -fno-strict-aliasing
%install
sh postfix-install -non-interactive install_root=%{buildroot}
config_directory=%{postfix_config_dir}
daemon_directory=%{postfix_daemon_dir}
command_directory=%{postfix_command_dir}
queue_directory=%{postfix_queue_dir} data_directory=%{postfix_data_dir}
sendmail_path=%{postfix_command_dir}/sendmail
newaliases_path=%{_bindir}/newaliases mailq_path=%{_bindir}/mailq
mail_owner=%{postfix_user} setgid_group=%{maildrop_group}
manpage_directory=%{_mandir} sample_directory=%{postfix_sample_dir}
readme_directory=%{postfix_readme_dir} || exit 1
install -c auxiliary/rmail/rmail %{buildroot}%{_bindir}/rmail
If there is a complaint here to be made, it is that perhaps
main.cf.default is largely obsolete (duplicates postconf -d),
and is perhaps no longer needed in $config_directory
agreed
Re: Blacklisting external domains
Am 06.02.2015 um 14:52 schrieb li...@rhsoft.net: Am 06.02.2015 um 14:43 schrieb Charles Marcus: Well... ok, so now I just have to figure out what I'm missing/doing wrong. Hmmm... ok, just moved it from smtpd_relay_restrictions to submission_client_restrictions and it works now... But it still looks to me like it should have worked when called from smtpd_relay_restrictions, or even smtpd_recipient_restrictions... it's simple * if there is any permit in front - well * if you are using specific submission_client_restrictions and have placed the access table in front of any permit it works in that context postfix is dead-simple the first action stops the rest inside of the restricition list, no matter if it is OK or REJECT and so if you have permit-rules like mynetworks or sasl-authenticated in front your access table is never called at all the same if you have a OK somewhere but another rule before says REJECT and BTW one reason more to make a transport it is not affected by other restrictions it just comes at the end of the chain when postfix now would accept the message even by a explicit OK in any restriction table http://www.postfix.org/transport.5.html exemple.com error:did you mean 'exAmple.com'?
Re: Blacklisting external domains
Am 06.02.2015 um 14:43 schrieb Charles Marcus: Well... ok, so now I just have to figure out what I'm missing/doing wrong. Hmmm... ok, just moved it from smtpd_relay_restrictions to submission_client_restrictions and it works now... But it still looks to me like it should have worked when called from smtpd_relay_restrictions, or even smtpd_recipient_restrictions... it's simple * if there is any permit in front - well * if you are using specific submission_client_restrictions and have placed the access table in front of any permit it works in that context postfix is dead-simple the first action stops the rest inside of the restricition list, no matter if it is OK or REJECT and so if you have permit-rules like mynetworks or sasl-authenticated in front your access table is never called at all the same if you have a OK somewhere but another rule before says REJECT
Re: Working around recalcitrant ISP wrt rDNS
Am 05.02.2015 um 14:50 schrieb Микаел Бак: Hi there, On 02/04/2015 11:06 PM, li...@rhsoft.net wrote: the truth is that a xx.xx.xx.xx-static-dsl.isp.tld is not a mailserver just becaus eit contains the word static - in fact most of them are ordinary office dsl lines with clients behind True. Not nessassarily a mail server, but it could be. it could give a clear sign that it is In Hungary a business line from one of the largest ISPs gives PTR like this: dsl.fixip.t-online.hu ( is actualy some rendom hex number). The ISP does not provide a way to change this PTR. frankly SPF is no rocket science and you don't need your ISP to configure that simple DNS record for your own domain Many small companies here run their own mailservers on behind thos dls lines together with their client machines. Not a vewry good idea to block those IMO then just *setup SPF* or make it on a DNSWL and that rules are completly skipped or just don't run your outbound mailserver on a standard DSL account and use a relay
Re: Reject domain but allow inbound for a local user
Am 05.02.2015 um 14:54 schrieb Inteq Solution - Dep. Tehnic: Thank you for taking your time to reply Wietse, I might have been a bit ambiguous about my problem. I know how to whitelist inbound u...@domain.com while rejecting the all other inbound from @domain.com My problem is: domainA.com is an external domain domainB.com is a domain hosted on my server. I REJECT all users of domainA.com from sending email to one of my domains, domainB.com domainA.com REJECT But, one user on domainB.com wants to receive email from any user on domainA.com This is the part where I am lost in reading the manual: allowing all email from domainA.com to domainB.com, but only for a certain user account on domainB.com. postfix don't support *any* configuration depending on sender *and* RCPT at the same time - you can configure restrictions only for the left or right side for anything else you need a ploicy-daemon or milter discussed recently more than once here
Re: Secure config - main.cf
Am 05.02.2015 um 22:00 schrieb SW: smtpd_tls_exclude_ciphers = aNULL, eNULL, DES, 3DES, MD5, DES+MD5, RC4 disable DES *and* Rc4 is pure nonsense because it leads in some servers not able to send mail to you at all and way more fall back to plain as needed
Re: Blacklisting external domains
Am 05.02.2015 um 22:19 schrieb Charles Marcus:
Ok, Can't seem to figure this out...
I want to block sending to certain domains - in this case, a domain that
is typod...
Googling suggests this should work:
smtpd_relay_restrictions = check_recipient_access
${hash}/blacklisted_domains, permit_sasl_authenticated,
permit_mynetworks, reject
blacklisted_domains contains
exemple.com REJECT did you mean 'exAmple.com'?
But querying the map only works for the plain TLD, not for email
addresses for the TLD.
# postmap -q exemple.com hash:/etc/postfix/maps/hash/blacklisted_domains
REJECT did you mean 'exAmple.com'?
# postmap -q recipi...@exemple.com
hash:/etc/postfix/maps/hash/blacklisted_domains
What am I missing?
that you can do that with a *transport*
on our submission servers we use mysql configs and have a seperate typo
transports table joined with the regular transports for years now
Re: Working around recalcitrant ISP wrt rDNS
Am 05.02.2015 um 15:28 schrieb Marcus Bointon: On 5 Feb 2015, at 14:58, li...@rhsoft.net wrote: ... you don't need your ISP to configure that simple DNS record for your own domain Actually you usually do. When anyone does a reverse lookup on your IP, it will point at the ISP's DNS, not yours, so unless you have reverse delegation set up on your ISP, creating your own PTR record is ineffective. To this end, most hosting ISPs (certainly all of mine do) provide a facility to configure reverse DNS entries in their name servers. what you you smoked to only quote the part of a sentence which makes no sense alone - I SAID frankly SPF is no rocket science and you don't need your ISP to configure that simple DNS record for your own domain so IF YOU DON'T be able to get your ISP change the PTR of your mailserver to match your maildomain AND you areg ignorant in case of make it do dnswl.org THEN setup SPF if you don't bother about PTR, SPF AND DNSWL you don't care about your outgoing mails - feel free to do so - but accept that other calling a mailadmin not take care of that incompetent for good reasons and i don't care how many and who agress in that point
Re: PATCH: PIE for Postfix 3.1
Am 05.02.2015 um 15:58 schrieb Christian Rößner: So at the moment I stay at my opinion that Postfix is running very stable wie PIE ans SSP. If I am wrong, please contact me offlist. Then I would have to do a lot of work to correct this problem. Hopefully not. ;-) postfix is running fine with PIE and -fstack-protector-all for years here as any other software, in the meantime -fstack-protector-strong reached GCC in several distribution for a good compromise of -fstack-protector not beeing enough these days and -fstack-protector-all has too much performance impact for too less gain Full RELRO Canary found NX enabledPIE enabled No RPATH No RUNPATH /usr/libexec/postfix/smtpd Full RELRO Canary found NX enabledPIE enabled No RPATH No RUNPATH /usr/libexec/postfix/postscreen the thread is more about still support PIE in combination of shared and upcoming Postfix 3.x
Re: TONE IT DOWN: Working around recalcitrant ISP wrt rDNS
Am 05.02.2015 um 16:08 schrieb Wietse Venema: li...@rhsoft.net: what you you smoked to only quote the part of a sentence which makes no Reindl, tone it down sorry, but that style of quote out-of-context and then explain me what a PTR is like i would not know such things better as most people calling themself admins was purely insulting Your spam load is not the same as what other people see my spam load would not be that high if all the zombies where out of game by unconditionally block outgoing port 25 worldwide and/or enforce SPF and PTR restrictions because the spammer business for infected zombies would disappear completly Do not assume that what works for you is good advice for the rest of the world. In my case, PTR-based rules do not solve any problem; my residual spam comes mainly from real MTAs. i don't bother at the end which filters others set, i just explained why it is a *damned good idea* to care about basics like a non-generic PTR, in best case matching in both directions and SPF (at least with ~all) helps *in general* all people on this planet to reduce the spam amount why? because every day other sender domains are forged and frankly if more people would refrain from setup a MTA without any knowledge i recently would not have been victim of a backscatter-flood because my domain was forged - backscatters even conatining the SPF-failed header and coming from a postmas...@xxx.xxx.local should in fact lead to fire the admin on the other side for a) accept while the RCPT on his side don't exists and a SPF hard-fail happened and b) bounce back the junk 90% of the PTR hits here are @yahoo.com, @gmail.com and @hotmail.com envelopes coming from 123.123.123.123-dsl-sombody.com.br likes
Re: Secure config - main.cf
Am 05.02.2015 um 22:26 schrieb SW: li...@rhsoft.net wrote Am 05.02.2015 um 22:00 schrieb SW: smtpd_tls_exclude_ciphers = aNULL, eNULL, DES, 3DES, MD5, DES+MD5, RC4 disable DES *and* Rc4 is pure nonsense because it leads in some servers not able to send mail to you at all and way more fall back to plain as needed Good point. Are you saying I *should* enable DES and RC4 so that I have SOME encryption rather than falling back to plain text? ie: smtpd_tls_exclude_ciphers = aNULL, eNULL, 3DES, MD5, DES+MD5 the other way - disable RC4 and leave DES in peace
Re: unable to send email TLS not offered by host
my first answer was rejected ridiculously because it contained the word subsc**e (BOUNCE postfix-users@postfix.org: Admin request of type /\bsubs***ibe\b/i at line 7 ) Weitergeleitete Nachricht Betreff: Re: unable to send email TLS not offered by host Datum: Thu, 05 Feb 2015 10:32:57 +0100 Von: li...@rhsoft.net li...@rhsoft.net An: postfix-users@postfix.org Am 05.02.2015 um 10:25 schrieb saulos: Hi I have a problem with one provider tiscali when try to send to him I get this error where is your postconf -n? postfix/smtp[13339]: 866B961BF5: TLS is required, but was not offered by host etb-4.mail.tiscali.it[213.205.33.62] Can I fix it or I will loose some security? smtp_tls_security_level = may if you don't want to find out a list of servers not supporting encryption by user complaints you decision if that mails can be sent unencrypted How I stop the server to keep try to send to this server? http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps
Re: Working around recalcitrant ISP wrt rDNS
Am 05.02.2015 um 11:03 schrieb lst_ho...@kwsoft.de:
You are putting too much of meaning in a DNS token. There is no global
rule or RFC about the interpretation of the string forming this token.
I'm totaly free to call my host bad-host-static-0815.example.com.
which is no problem because it don't match
[\.\-]?[0-9]{1,3}[\.\-][0-9]{1,3}[\.\-][0-9]{1,3}[\.\-][0-9]{1,3}[\.\-]
There are a lot of zombies in the *.comcastbusiness.* PTR space, but
you throw out the baby with the bathwater. There are other ways to
get rid of the zombies on static IPs without wholesale blocking.
Greylisting and a couple reliable RBLs (or postscreen) will block
the vast majority of zombies without wholesale slaughter.
you did not get the point:
if PTR's with a IP-part would be rejected worldwide and ISP's would
block outgoing port 25 for homeusers the business of infect client PCs
to send out malware to MX hosts would die from one day to the next
* greylisting does *much* more harm be it for large senders
retry with a dfiierent IP or sender verification on the
other side for your own outgoing mail
It is true that it is more burden for the sender, but that is *always*
the case with spam preventing systems
no it's not always
greylisting slows down legit mail too
* all the dialupo RBLs are far from complete
You don't need them
* other RBLs are way too late, if someone makes it on them
he already had sucess in send his crap out
With greylisting the RBL has time to settle
with a well desigend PTR filter you don't have the delay of greylisting
and 95% of the PTR rejects are *later* in enough of the 28 RBL's of the
postscreen mix - it looks like below
---
195-154-48-147.rev.poneytelecom.eu (195.154.48.147)
* RBL: b.barracudacentral.org
* RBL: bl.mailspike.net
* RBL: dnsbl.inps.de
* RBL: dnsbl.sorbs.net
* RBL: dnsbl-uce.thelounge.net
* RBL: zen.spamhaus.org
Jan 29 22:57:40: 195-154-48-147.rev.poneytelecom.eu: PTR 615; ;
Jan 30 05:38:49: RBL inps.de; ;
Jan 30 05:39:00: RBL inps.de; ;
Jan 30 05:39:10: RBL inps.de; ;
Jan 30 05:39:17: RBL inps.de; ;
---
* there is no single reason for not have a sane PTR
I'm free to call my hosts as i like as long as it is a valid DNS token
surely, you are free to configure your server in a way to get delivery
problems and since a lot of customers only hosting DNS here insisted to
get a SPF record for avoid their mails going to the spam folder at gmail
and other large providers virtually nobody has such a generic PTR and at
the same time no SPF *and* no DNSWL entry
* postfix has even a setting that A/PTR needs to *match*
and if someone enables that we no longer dicuss about
the PTR part in the reverse DNS at all
This is not related at all. With a matching PTR there is some *week*
evidence that i'm the owner of the IP, nothing more.
it * is* related because if it is no longer a 123.123.123.123.isp.tld
but your domain it is *not* some infected *enduser machine* and all the
dialup-rbls are far away from complete
See, even you don't block everyone with an offending PTR -- you
check for valid SPF or dnswl
because the intention is *not* to block mailservers
a random enduser IP i not listed in the SPF record nor on DNSWL's
We don't care about DNS names and we do not even check for matching PTR
or SPF,DNSWL and the like and still our spam ratio reaching the inbox
from random dial-ups is below 5%. The vast majority of spam are the
famous freemailer like Yahoo,Hotmail,Google some hacked edu-accounts and
the well connected SPF/PTR whatever clean spam centers around the world.
that are *your values*
we have some hundret domains and around 1200 mailusers
97% of the 473209 in the last month rejected by RBL would
have hit the PTR filters too and 90% of all incoming legit mail have SPF
or are on one or more DNSWL
Connections: 531224
Delivered: 58015
Blocked: 473209
So no, to construct some meaning to DNS token which is not there is not
useful at all.
for you - that may change quickly
there are days with no single RBL reject and then there are days where
within 20 minutes 50 dead-safe phishing mails are blocked where the
sending IP is not on enough of the 28 RBL's in the postscreen mix and
SpamAssassin catches only parts of that or is way too epensive when the
amount of incoming trash get too high
Re: Working around recalcitrant ISP wrt rDNS
Am 04.02.2015 um 22:54 schrieb Noel Jones:
On 2/4/2015 3:12 PM, li...@rhsoft.net wrote:
*sadly* that sort of incoming rules is not widespreaded enough,
otherwise spam from infected botnet zombies would no longer exist
and frankly the rule for IPhfc.comcastbusiness.net is manually
written by look at the incoming junk amount all day long hitting the
contentfilter and no single legit mail without SPF/DNSWL over months
/^[\.\-]?([0-9]{1,3}[\.\-]){2,4}[\.\-]?[a-z]{4,20}[\.\-]hfc[\.\-]comcastbusiness[\.\-](co|com|net|org)$/
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 435) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework
even if it is not a directly reject *every* SpamAssassin setup on
this planet gives you a penalty for such a PTR and that maybe the
last piece needed for a milter-reject - in that case you don't know
the reasons, with the reject above you do
score RDNS_DYNAMIC 2.639 0.363 1.663 0.982
score NO_RDNS_DOTCOM_HELO 3.100 0.433 3.099 0.823
Your filter is broken if it can't tell the difference between a
static and dynamic PTR.
your mailsetup is broken if you don't care about basics like a sane PTR
and frankly even the admin before me not cared about much things
insisted more than 10 years ago the we never ever send out mails from a
generic PTR
the truth is that a xx.xx.xx.xx-static-dsl.isp.tld is not a mailserver
just becaus eit contains the word static - in fact most of them are
ordinary office dsl lines with clients behind
There are a lot of zombies in the *.comcastbusiness.* PTR space, but
you throw out the baby with the bathwater. There are other ways to
get rid of the zombies on static IPs without wholesale blocking.
Greylisting and a couple reliable RBLs (or postscreen) will block
the vast majority of zombies without wholesale slaughter.
you did not get the point:
if PTR's with a IP-part would be rejected worldwide and ISP's would
block outgoing port 25 for homeusers the business of infect client PCs
to send out malware to MX hosts would die from one day to the next
* greylisting does *much* more harm be it for large senders
retry with a dfiierent IP or sender verification on the
other side for your own outgoing mail
* all the dialupo RBLs are far from complete
* other RBLs are way too late, if someone makes it on them
he already had sucess in send his crap out
* there is no single reason for not have a sane PTR
* postfix has even a setting that A/PTR needs to *match*
and if someone enables that we no longer dicuss about
the PTR part in the reverse DNS at all
See, even you don't block everyone with an offending PTR -- you
check for valid SPF or dnswl
because the intention is *not* to block mailservers
a random enduser IP i not listed in the SPF record nor on DNSWL's
Re: Working around recalcitrant ISP wrt rDNS
Am 04.02.2015 um 21:51 schrieb Noel Jones:
On 2/4/2015 2:37 PM, li...@rhsoft.net wrote:
it don't matter if it matches - if you are coming with such a PTR
you are rejected - on my setup this is skipped at least if the
envelope domain has a SPF policy listing that IP or if you are on
one of 11 public DNSWL
ptr-check.sh 50-253-254-9-static.hfc.comcastbusiness.net
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 417) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework
Your server, your rules. Thankfully this sort of incoming rule
isn't widespread.
*sadly* that sort of incoming rules is not widespreaded enough,
otherwise spam from infected botnet zombies would no longer exist and
frankly the rule for IPhfc.comcastbusiness.net is manually written
by look at the incoming junk amount all day long hitting the
contentfilter and no single legit mail without SPF/DNSWL over months
/^[\.\-]?([0-9]{1,3}[\.\-]){2,4}[\.\-]?[a-z]{4,20}[\.\-]hfc[\.\-]comcastbusiness[\.\-](co|com|net|org)$/
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 435) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework
even if it is not a directly reject *every* SpamAssassin setup on this
planet gives you a penalty for such a PTR and that maybe the last piece
needed for a milter-reject - in that case you don't know the reasons,
with the reject above you do
score RDNS_DYNAMIC 2.639 0.363 1.663 0.982
score NO_RDNS_DOTCOM_HELO 3.100 0.433 3.099 0.823
if a postmaster is not able to
* care about a PTR not containing an IP
* care about make it on one of the many DNSWL
* setup SPF properly
he don't care about relieable delivery, otherwise he would at least use
a sane relay-host
Which reminds me that the OP should register his domain and IP on
dnswl.org (free and easy)
junkemailfilter.com LISTED 127.0.0.5
exists for our range even without do anything
permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.[1;3;5]
__
ips.whitelisted.org
list.dnswl.org
wl.mailspike.net
iadb.isipp.com
sa-accredit.habeas.com
dnswl.inps.de
swl.spamhaus.org
junkemailfilter.com
Re: Working around recalcitrant ISP wrt rDNS
Am 04.02.2015 um 20:47 schrieb Robert Moskowitz: I have been 'working' with my new ISP for a couple weeks to get the rDNS setup for my server move (I am changing ISPs for a number of reasons). I was assured on signing that setting up rDNS was 'easy'; it is not. DIGing up the SOA on my IP rDNS tends to indicate that they have not updated that zone for many months. RDNS is a prerequisite *before* setupa MTA not the other direction And that 50-253-254-9-static.hfc.comcastbusiness.net has no RR (e.g. A or CNAME). Is there someway to get postfix to provide the needed inforation to the recipient MTA that this is OK and valid? you and your postfix are not in the position to provide any infromation i that context - the receiving MTA asks for the PTR of the connecting IP I am asking, but I suspect that even if I send out things OK, there will be MTAs out there that will not let their clients send mail to me as my rDNS does not match. it don't matter if it matches - if you are coming with such a PTR you are rejected - on my setup this is skipped at least if the envelope domain has a SPF policy listing that IP or if you are on one of 11 public DNSWL ptr-check.sh 50-253-254-9-static.hfc.comcastbusiness.net REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 417) see http://www.emailtalk.org/ptr.aspx or configure http://en.wikipedia.org/wiki/Sender_Policy_Framework I am pushing the ISP that will remain unnamed. (oops. :) ) I was told that 'they are working on it'. Meanwhile I am paying double as I cannot migrate my server. 'they are working on it'? they are idiots - it takes 5 seconds to change the Reverse DNS for the IP to mail.htt-consult.com on their nameservers and the A-record is completly in your hands well, because i got tired about how long ISP's need for simple changes and then more than once *add* the requested PTR instead replace it and so email becomes a lottery i had a fight to get the reverse zone for our /24 delegated to my own nameservers and so now control each record as well as the TTL
Re: ot: hotmail bouncing since two days ago, is there some new requiremtns?
what exactly did you not understand in: Unfortunately, messages from 103.15.178.123 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors; Am 04.02.2015 um 22:53 schrieb Voytek: ot: I have Postfix running mail server for several small domains, all working well. since about 48 hours, several of my domains started getting bounced from hotmail as per below checked with mxtoolbox, mail server is: Checking emu.sbt.net.au which resolves to 103.15.178.123 against 100 known blacklists... Listed 0 times with 3 timeouts has hotmail changed or enforced something new in the last few days ? is there something I should do on my Postfix ? dns ? yesterday, I've added dns record as below, is that a must have ? TXT sbt.net.au 60 min v=spf1 a mx ~all -- Feb 5 07:06:45 emu postfix/smtp[32527]: EF7CC24E008: to=tt...@outlook.com, relay=mx3.hotmail.com[65.55.37.88]:25, delay=2.4, delays=0.49/0.04/1.6/0.19, dsn=5.0.0, status=bounced (host mx3.hotmail.com[65.55.37.88] said: 550 SC-001 (COL004-MC2F25) Unfortunately, messages from 103.15.178.123 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL FROM command)) Feb 5 07:06:45 emu postfix/smtp[32527]: EF7CC24E008: lost connection with mx3.hotmail.com[65.55.37.88] while sending RCPT TO
Re: TUNING_README: persistent write cache?
Am 04.02.2015 um 15:40 schrieb Andrew Bourgeois: But what does persistent write cache mean? What needs to be changed on the OS level? Google doesn't clearly link persistent write cache to a Linux feature. https://www.google.at/#q=write+cache+storage https://www.google.at/search?q=bbu+storage
Re: Forwarding to Gmail
Am 04.02.2015 um 16:39 schrieb LuKreme: Quite a few users are forwarding their mail to either yahoo or gmail, which is causing a lot of trouble because both services see spam being forwarded and blacklist the sending server (me). Gmail at least seems to calm down after a little while, but delays on some mail can be many hours. These are users who are setting their own forwarding up via postfixadmin and getting forwarded by postfix based on the mysql lookup in proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, so the messages aren’t getting filtered at all (beyond what postscreen can do, of course) just setup SpamAssassin and ClamAV as *milter* and they are filtered unconditional until you define no_milters in master.cf for a specific service that way we have spamass-milter in front of the MX delivering to a dedicated port filtering incoming and already scanned messages to the final destinations while all other ports for submission are going through the outgoing spamass-milter with it's own rule configs
Re: Receiving email from Everbridge alert systems
Am 04.02.2015 um 16:30 schrieb francis picabia: I'm not aware we can introduce exemptions for smtpd_client_connection_rate_limit smtpd_client_message_rate_limit If anyone has already tweaked Postfix to accommodate the Everbridge alert system, do you want to share what helped? you can easily implement rate controls with iptables recent and remove specific IP's or subnets bevor apply the rule - IMHO connection ratecontrols belongs anyways to the network / firewall layer and not in the application layer at all iptables -I INPUT -p tcp --dport 25 -m conntrack --ctstate NEW -m recent --name postfix1 --set iptables -I INPUT -p tcp -s $SOURCE_RANGE -m conntrack --ctstate NEW -m recent --remove iptables -I INPUT -p tcp --dport 25 -m conntrack --ctstate NEW -m recent --name postfix1 --update --seconds 1800 --hitcount 60 -j REJECT iptables -I INPUT -p tcp --dport 25 -m conntrack --ctstate NEW -m recent --name postfix1 --update --seconds 1800 --hitcount 60 -m limit --limit 60/h -j LOG --log-prefix Firewall Rate-Control:
Re: Problems building 3.0 with dynamic module support
Am 04.02.2015 um 03:31 schrieb Peter: On 02/04/2015 02:47 PM, Viktor Dukhovni wrote: It may be tricky, Postfix applies AUXLIBS when building both the final executables, and the shared libraries, but it seems that -pie is not appropriate for shared libraries. Additinal makedefs and Makefile.in logic would be required to create linker flags that apply to the executables only. Well for now, then I'll just have to remove -pie, but if I can get that in as a feature request to make -pie work with shared=yes, then I would really appreciate it. Not sure if it should be considered a blocker for 3.0.0 or not, though, maybe it could be considered a bugfix to go into 3.0.1? looks like you don't realize the difference between PIC and PIE PIE = position independent EXECUTABLE PIC = position independent CODE shared libraries (at least on x86_64) are always PIC see the difference between a .so and a executeable below Full RELRO Canary found NX enabledDSO No RPATH No RUNPATH /usr/lib64/mysql/libmysqlclient.so.18.0.0 Full RELRO Canary found NX enabledPIE enabled No RPATH No RUNPATH /usr/libexec/mysqld
Re: Change sender in php
Am 03.02.2015 um 13:17 schrieb Danny: I have postfix setup on a Debian system that manages all my mail. However, whenever php is sending mail it sends it under user www-data. I tried changing the headers in php but it remains the same. Is there someway I can change this to a more friendly name via postfix? It is not a train smash, just curious the header is you smallest problem the envelope is because if the destination server does sender-verification you www-data@soime-radnom-host likely don't exist just don't use the mail() function in PHP https://code.google.com/a/apache-extras.org/p/phpmailer/downloads/list i never understood why people using that function since we disabled it more than 12 years ago on any server completly ___ http://www.postfix.org/canonical.5.html cat /etc/postfix/canonical # CANONICAL(5) # # NAME #canonical - Postfix canonical table format # # SYNOPSIS #postmap /etc/postfix/canonical # #postmap -q string /etc/postfix/canonical # #postmap -q - /etc/postfix/canonical inputfile apache@localhost postmaster@localhost
Re: Problems building 3.0 with dynamic module support
Am 03.02.2015 um 23:35 schrieb Peter: On 02/04/2015 11:31 AM, Viktor Dukhovni wrote: make makefiles shared=yes 'CCARGS=-fPIC' 'AUXLIBS=-fPIE -pie' ...fails Of course it does. You used both -fPIE and -fpie. No, I used both -fPIE and -pie (without the f) BUT one belongs to CCARGS and the other to AUXLIBS re-read the previous mails in this thread!
Re: Problems building 3.0 with dynamic module support
Am 04.02.2015 um 02:31 schrieb Peter:
On 02/04/2015 01:42 PM, li...@rhsoft.net wrote:
BUT one belongs to CCARGS and the other to AUXLIBS
re-read the previous mails in this thread!
...and from one of *my* previous emails:
make makefiles shared=yes 'CCARGS=-fPIC -fPIE' 'AUXLIBS=-pie'
...also fails
Can you suggest the combination with -pie that is supposed to work and
actually *does* work?
not for dynamic build but that below is from my rpmbuilder and it's a
hardened build supporting ASLR
hardening-check /usr/libexec/postfix/master
/usr/libexec/postfix/master:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: yes
.rpmrc:
optflags: x86_64 -m64 -O2 -march=corei7 -mtune=corei7 -fopenmp -mmmx
-msse2 -msse3 -msse4.1 -msse4.2 -maes -mfpmath=sse -pipe
-fomit-frame-pointer -finline-functions -finline-limit=60 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=6 -D_FORTIFY_SOURCE=2
-Wstack-protector -Wformat -Werror=format-security
postfix.spec:
%build
CCARGS=-fPIC -DNO_NIS -DNO_NISPLUS -DNO_EAI -DNO_LMDB -DNO_CDB
-DNO_LDAP -DNO_PGSQL -DNO_SQLITE -DHAS_PCRE -I%{_includedir}/pcre
-DHAS_MYSQL -I%{_includedir}/mysql -DUSE_TLS -DUSE_SASL_AUTH
-DUSE_CYRUS_SASL -I%{_includedir}/sasl
-DDEF_CONFIG_DIR=\\\%{postfix_config_dir}\\\
AUXLIBS=-lpcre -L%{_libdir}/mysql -lmysqlclient -lm -L%{_libdir}/sasl2
-lsasl2 -lssl -lcrypto -pie -Wl,-z,now -Wl,-z,relro,-z,noexecstack
%{__make} %{?_smp_mflags} -f Makefile.init makefiles shared=no
CCARGS=${CCARGS} AUXLIBS=${AUXLIBS} DEBUG= OPT=%{optflags}
-Wno-comment -fno-strict-aliasing
%{__make} %{?_smp_mflags} CCARGS=${CCARGS} AUXLIBS=${AUXLIBS}
DEBUG= OPT=%{optflags} -Wno-comment -fno-strict-aliasing
Re: Am I backscattering?
Am 01.02.2015 um 10:01 schrieb LuKreme: On Jan 31, 2015, at 9:29 PM, Bill Cole postfixlists-070...@billmail.scconsult.com wrote: Which doesn't mean you don't have some other Postfix binaries lurking... Good point. There are files in /usr/sbin/ and in /usr/local/sbin/ and it appears that the command directory is set to the latter, which appears to be 2.10.5 Seeing what breaks if I switch the command directory. I would *never* have found that. if you build software from source build native packages for your OS, that cleans up things and avoids the system pulling the OS vendors version which conflicts with something below /usr/local on most distributions the package is pulled because requirement of /usr/sbin/sendmail of other packages as dependency i am using a self built postfix RPM based on the Fedora SPEC since doing more than relay from localhost with postfix and it's always the newest version and installed below /usr as like a distribution package
Re: TLS Library Problem
Am 01.02.2015 um 22:26 schrieb LuKreme: On 01 Feb 2015, at 05:41 , DTNX Postmaster postmas...@dtnx.net wrote: By the way, CA-signed certificates start at less than $10/year, so if you ever do run into an issue which might be resolved by getting one, and your configuration isn't too complex, I would suggest spending that little bit of money. Not the case here though, as far as I can tell :-) Thanks for the detailed response. The issue with the certs is not the cost, but rather the maintenance of them. I don’t do this full-time and the interval between expiry is long enough that I get to learn everything over from first principles every time I have to replace a cert. why? just make it once in your lifetime, create a template for default params and a script with minimal maintainance like for hash-method and keylength - the script below in any case builds a self signed PEM with key and cert as well as the CSR for submit to a CA after you get back the signed crt just replace that one part in the PEM and you are done - creating certs that way for 10 years now [root@localhost~]$ cat generate-cert.sh #!/usr/bin/bash umask 066 WORKING_DIR=/buildserver/ssl-cert read -e -p SERVER NAME: COMMON_NAME if [ $COMMON_NAME == ]; then exit fi OUT_DIR=$WORKING_DIR/$COMMON_NAME mkdir $OUT_DIR 2 /dev/null chmod 0700 $OUT_DIR read -e -p KEY LENGTH: -i 4096 KEY_LENGTH read -e -p HASH METHOD: -i sha256 HASH_METHOD echo Random-Seed RANDOM_FILE=$OUT_DIR/random-seed touch $RANDOM_FILE chmod 0600 $RANDOM_FILE dd if=/dev/random of=$RANDOM_FILE bs=1 count=1024 2 /dev/null sleep 2 rm -f $OUT_DIR/$COMMON_NAME.key rm -f $OUT_DIR/$COMMON_NAME.csr rm -f $OUT_DIR/$COMMON_NAME.crt rm -f $OUT_DIR/$COMMON_NAME.pem rm -f $OUT_DIR/$COMMON_NAME.ec rm -f $OUT_DIR/$COMMON_NAME.dh rm -f $OUT_DIR/$COMMON_NAME.ecdh sed s/my_common_name/$COMMON_NAME/g $WORKING_DIR/openssl.conf.template $WORKING_DIR/openssl.conf openssl req -config $WORKING_DIR/openssl.conf -nodes -$HASH_METHOD -newkey rsa:$KEY_LENGTH -keyout $OUT_DIR/$COMMON_NAME.key -out $OUT_DIR/$COMMON_NAME.csr -rand $RANDOM_FILE openssl x509 -$HASH_METHOD -req -days 3650 -in $OUT_DIR/$COMMON_NAME.csr -signkey $OUT_DIR/$COMMON_NAME.key -out $OUT_DIR/$COMMON_NAME.crt cat $OUT_DIR/$COMMON_NAME.crt $OUT_DIR/$COMMON_NAME.key $OUT_DIR/$COMMON_NAME.pem openssl ecparam -out $OUT_DIR/$COMMON_NAME.ec -name prime256v1 openssl gendh -out $OUT_DIR/$COMMON_NAME.dh -2 2048 -rand $RANDOM_FILE:$OUT_DIR/$COMMON_NAME.key cat $OUT_DIR/$COMMON_NAME.ec $OUT_DIR/$COMMON_NAME.pem cat $OUT_DIR/$COMMON_NAME.dh $OUT_DIR/$COMMON_NAME.pem cat $OUT_DIR/$COMMON_NAME.ec $OUT_DIR/$COMMON_NAME.dh $OUT_DIR/$COMMON_NAME.ecdh rm -f $OUT_DIR/$COMMON_NAME.ec rm -f $OUT_DIR/$COMMON_NAME.dh chmod 600 $OUT_DIR/* touch $OUT_DIR/* echo /bin/ls -l -h --color=tty -X --group-directories-first --time-style=long-iso $OUT_DIR/$COMMON_NAME.csr /bin/ls -l -h --color=tty -X --group-directories-first --time-style=long-iso $OUT_DIR/$COMMON_NAME.key /bin/ls -l -h --color=tty -X --group-directories-first --time-style=long-iso $OUT_DIR/$COMMON_NAME.crt /bin/ls -l -h --color=tty -X --group-directories-first --time-style=long-iso $OUT_DIR/$COMMON_NAME.pem echo rm -f $WORKING_DIR/openssl.conf rm -f $RANDOM_FILE sync
Re: TLS Library Problem
Am 01.02.2015 um 23:15 schrieb Viktor Dukhovni: On Sun, Feb 01, 2015 at 10:32:53PM +0100, li...@rhsoft.net wrote: just make it once in your lifetime, create a template for default params and a script with minimal maintainance like for hash-method and keylength - the script below in any case builds a self signed PEM with key and cert as well as the CSR for submit to a CA For MX hosts there is no reason to bother with public CAs, even when the CA certs are free. Just set the expiration date a few centuries into the future, and replace the cert when you feel the key has been around long enough, rather than based on a pre-set deadline. For MSAs offering service to Joe Public, sure you'll want a CA-issued cert. i only referred to the interval between expiry is long enough that I get to learn everything over from first principles every time I have to replace a cert
Re: hostname does not resolve
Am 01.02.2015 um 04:59 schrieb Bill Cole: On 31 Jan 2015, at 17:33, LuKreme wrote: What should I do about these warnings? Is there any reason not to reject the IPs in question? And if not, how do I do so? mail_version = 2.11.3 warning hostname 102-253-144-216.static.reverse.lstn.net does not resolve to address 216.144.253.102 hostname nor servname provided, or not known warning hostname 138-128-178-101.static.dimenoc.com does not resolve to address 138.128.178.101 hostname nor servname provided, or not known warning hostname 158-33-143-63.static.reverse.lstn.net does not resolve to address 63.143.33.158 hostname nor servname provided, or not known warning hostname 174-120-162-69.static.reverse.cascompany.com does not resolve to address 69.162.120.174 hostname nor servname provided, or not known Those *SPECIFIC* IPs are probably not offering anything worth passing to SpamAssassin or any other deep inspection. A quick check says they're all on the SpamHaus CSS (snowshoe spammers) and the PSBL but that log messages are only informative Nearly every SMTP client using an IP with a PTR whose name does not resolve back to that IP sends nothing but spam bullshit - in the real world that's not true additionally every machine having more than 1 PTR will *randomly* hit that and if you configure your server to reject mail because not matching http://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS you need to make sure it is your private server and you know every single sender additionally in many cases one has not *full* control of that and so you need at least to bypass such restricitons in case of SPF-PASS and/or well known DNSWL until you are asking for troubles and support calls postfix has a simple setting but you can't use it in production http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
Re: hostname does not resolve
Am 01.02.2015 um 05:45 schrieb Viktor Dukhovni: On Sun, Feb 01, 2015 at 05:11:15AM +0100, li...@rhsoft.net wrote: Nearly every SMTP client using an IP with a PTR whose name does not resolve back to that IP sends nothing but spam bullshit - in the real world that's not true The message you were responding too was generally helpful with suitable caveats. Opinions differ, Let's keep the tone civil... agreed - but sends nothing but spam is wrong and everybody adjusting his config by that will learn it the hard way after user complaints
Re: unused parameter: mx_access=hash:/etc/postfix/mx_access
Am 31.01.2015 um 05:49 schrieb Joey J: I'm getting the following when I start postfix ( literally that many times) /usr/sbin/postconf: warning: /etc/postfix/main.cf http://main.cf: unused parameter: mx_access=hash:/etc/postfix/mx_access Here is a section of my configuration, I cant' seem to figure out what I'm doing wrong. -- virtual_maps = hash:/etc/postfix/virtual hash:/etc/postfix/local-host-names alias_maps = hash:/etc/postfix/aliases mx_access = hash:/etc/postfix/mx_access relay_domains = /etc/postfix/backup_domains transport_maps = hash:/etc/postfix/transport, hash:/etc/postfix/transport_bounce relay_recipient_maps = hash:/etc/postfix/backup_domains_recipients, hash:/etc/postfix/transport_recipients as postfix telss you mx_access = hash:/etc/postfix/mx_access is the only line where you use it which is pointless until a variable is used in a smtpd_*_restricitions or somewhere else in other words: there is no such config parameter directly in main.cf because postfix needs to know *where* to apply it and in which order go to that page, type CTRL+F followed by mx_access http://www.postfix.org/postconf.5.html check_client_mx_access type:table Search the specified access(5) database for the MX hosts for the client hostname, and execute the corresponding action. Note: a result of OK is not allowed for safety reasons. Instead, use DUNNO in order to exclude specific hosts from blacklists. This feature is available in Postfix 2.7 and later.
Re: Unable to receive mail: Relay access denied
Am 30.01.2015 um 14:59 schrieb Andreas Fagschlunger: What I found out so far is, that postfix doesn't feel responsible for mydomain.com. When I change mydestination to mydomain.com, postfix accepts mails. But I want postfix to lookup the domain against mysql. I've read all the tutorials around and I'm still getting this error. I tested my SQL queries with postmap -q and they seem to work fine So I enabled verbose logging on smtpd and I didn't find any SQL query, so I think postfix isn't even accessing the database don't do that and postconf -d output that is luckily not true and you posted correct postconf -n alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id sleep 5 html_directory = no local_recipient_maps = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man mydestination = newaliases_path = /usr/bin/newaliases readme_directory = /usr/share/doc/postfix sample_directory = /usr/share/doc/postfix/examples sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key unknown_local_recipient_reject_code = 550 virtual_gid_maps = static:8 virtual_mailbox_base = /var/vmail virtual_mailbox_maps = mysql:/etc/postfix/virtual_mailbox_maps.cf virtual_uid_maps = static:999 Now why postfix doesn't lookup mydomain.com over MySQL? because you don't define virtual_mailbox_domains which lists *domains* while virtual_mailbox_maps is the RCPT table http://www.postfix.org/postconf.5.html#virtual_mailbox_maps virtual_mailbox_maps (default: empty) Optional lookup tables with all valid addresses in the domains that match $virtual_mailbox_domains. http://www.postfix.org/postconf.5.html#virtual_mailbox_domains
Re: A strange problem when adding DSPAM to Postfix
Am 29.01.2015 um 17:52 schrieb Орхан Ибад-оглы Гасымов: But if my current way of applying a content filter is not correct, then with correct config like in examples: smtp inet n - n - - smtpd -o content_filter=lmtp:unix:/var/run/dspam.sock if you write it taht way it is completly wrong smtp inet n - n - - smtpd -o content_filter=lmtp:unix:/var/run/dspam.sock versus smtp inet n - n - - smtpd -o content_filter=lmtp:unix:/var/run/dspam.sock the space before -o means the previous line is continued what you really want to achieve is the following and the breaks with ident are for better readability smtp inet n - n - - smtpd -o content_filter=lmtp:unix:/var/run/dspam.sock
Re: A strange problem when adding DSPAM to Postfix
please don't top-post and don't link to external ressources especially not ones require javascript * output of pstconf -n * master.cf * directly into the mail the whole sentence with unders smtp and not under smtps makes no sense Am 29.01.2015 um 11:25 schrieb Орхан Ибад-оглы Гасымов: Personally for me, it's an interesting situation: DSPAM works, but tags only local mail; other mail is delivered as if there's no content filter at all. Maybe something is wrong with my master.cf http://master.cf file? If anyone here used Postfix with DSPAM, please take a look at my Postfix configs, I'm stuck in this situation and don't know what troubleshooting steps to take further. 2015-01-29 11:03 GMT+04:00 Орхан Ибад-оглы Гасымов gasymov...@vfmgiu.ru mailto:gasymov...@vfmgiu.ru: I read the file postfix.txt in shared docs of DSPAM, but I can't make DSPAM insert any headers into mails if I only specify it as a content filter under smtp in master.cf http://master.cf, and not under smtps. Probably my configuration files (with stripped comments) will explain everything better: dspam.conf: https://cloud.mail.ru/public/8eda6c0df06a/dspam.conf.txt master.cf http://master.cf: https://cloud.mail.ru/public/7a06ab781307/master.cf.txt main.cf http://main.cf: https://cloud.mail.ru/public/2dd1062220e2/main.cf.txt For simplicity of my first setup, I installed DSPAM on the same machine as Postfix, and configured it to use libhash_drv.so, not other DB drivers. Software versions are the latest DSPAM and Postfix installed on FreeBSD 10.0. I didn't change too many defaults in configs, but maybe I've misconfigured something so obvious that any experienced user will be able to point it out right away. Please help me to find the error, any help is highly appreciated! 2015-01-28 23:05 GMT+04:00 Орхан Ибад-оглы Гасымов gasymov...@vfmgiu.ru mailto:gasymov...@vfmgiu.ru: ...on the dspam list are for sure more people using dspam as here - probably correct. That's why I started conversation with a question: Did anyone had this type of misconfiguration before? If nobody on this list ever used DSPAM, then there's no point to bother list users with questions about Postfix - DSPAM interaction. 2015-01-28 22:50 GMT+04:00 k...@rice.edu mailto:k...@rice.edu k...@rice.edu mailto:k...@rice.edu: On Wed, Jan 28, 2015 at 10:44:27PM +0400, Орхан Ибад-оглы Гасымов wrote: Thanks for your reply. 2. ...dspam is abandonware - thanks for an interesting piece of information. This statement is unsupported. It is not being developed agressively which seems to provoke this person.
Re: A strange problem when adding DSPAM to Postfix
Am 29.01.2015 um 19:03 schrieb Орхан Ибад-оглы Гасымов: This message was really informative, thanks. Actually in my configs I use spaces where needed, it's just my mail client deletes spases if they are the first character of a sentence. I didn't find anything useful in DSPAM logs, but I'll take a second look at them tomorrow. The only thing I'd like to ask now is: is it possible with Postfix to redirect mail from port 25 to port 465? If yes, I'd like to check such a setup. that makes no sense at all postfix listens on both and receives incoming mail, that's it port 465 is *smtp over ssl* and only useable for *mail clients* no MTA can deliver mail over the wrapper mode nor will any MTA connect to something else than 25 frankly i don't get the idea apply the contentfilter at all on 465 because that can only be a MUA for submission and is not incoming mail at all (outgoing mail needs a complete different ruleset hence you normally have different machines for MX and for submission) 2015-01-29 21:39 GMT+04:00 Noel Jones njo...@megan.vbhcs.org mailto:njo...@megan.vbhcs.org: On 1/29/2015 10:52 AM, Орхан Ибад-оглы Гасымов wrote: I always intend to understand configs that I take from examples. The problem is, almost all examples describing master.cf http://master.cf http://master.cf say to put the string: -o content_filter=lmtp:unix:/var/run/dspam.sock under smtp inet n - n - - smtpd Yes, that is the correct way to enable a content filter for mail coming from the internet. Note the second line must be indented with at least one space character. Your dspam filter will certainly never work without this line. In my setup, if I do so, it accomplishes nothing: DSPAM doesn't tag headers at all. What worked in my case for local mails, was the same string -o content_filter=lmtp:unix:/var/run/dspam.sock under smtps inet n - n - - smtpd Then DSPAM started to tag headers for mail from local users. Yes, that enables the same content filter for mail arriving via the smtps port 465. That shows you postfix really does call dspam when told to. Once you eliminate the possibility of master.cf http://master.cf syntax errors, then the problem is outside postfix and you need to look at your dspam logging and config
Re: Glibc Vulnerability -- CVE-2015-0235
Am 28.01.2015 um 15:38 schrieb Benny Pedersen: On 28. jan. 2015 14.57.27 li...@rhsoft.net li...@rhsoft.net wrote: all serious distributions have a newer glibc or offer updates Jan 28 05:41:58 Updated: glibc-common-2.5-123.el5_11.1.x86_64 Jan 28 05:42:03 Updated: glibc-2.5-123.el5_11.1.x86_64 what version of glibc is that? the version of RHEL5 with the update did you verify it solves all the cve in glibc 2.20? it don't need to because it don't contain the CVE's introduced in later versions, it just needs to fix the present ones did you even google cve on glibc ? the topic is about CVE-2015-0235 and i can read changelogs of rpm packages (the good thing in pre-compiled packages) * Mon Jan 19 2015 Siddhesh Poyarekar siddh...@redhat.com - 2.5-123.1 - Fix parsing of numeric hosts in gethostbyname_r (CVE-2015-0235) now you are again ignored here i better don't say what *especially you* deserve for such a line
Re: Glibc Vulnerability -- CVE-2015-0235
Am 28.01.2015 um 07:18 schrieb Benny Pedersen: On 28. jan. 2015 06.50.31 Peter pe...@pajamian.dhs.org wrote: Honestly, I don't know if postfix uses that function or not, but if postfix isn't vulnerable then you almost certainly have some other program on your box that is. I would recommend that you update glibc without delay regardless. bug is resolved in glibc 2.18, and possible other distros with lots of backports, in gentoo its glibc 2.19 stable, note update glibc can not be reversed in terms of version numbers, so be sure to ask maintainers first all serious distributions have a newer glibc or offer updates Jan 28 05:41:58 Updated: glibc-common-2.5-123.el5_11.1.x86_64 Jan 28 05:42:03 Updated: glibc-2.5-123.el5_11.1.x86_64
Re: warning: maildrop/33CAC20FBB: error writing BFF19213F8: queue file write error
Am 28.01.2015 um 15:28 schrieb deoren: I searched via Google and via the mailing list archives, but I didn't find a post which matched my specific situation. I see those warnings in the logs when the system goes down for a reboot. Is the mail lost? Should I be using a different approach when rebooting a server running Postfix? Does the client receive an error and it's then up to it to try again? you need to provide the loglines before *and* after that message anyways, that's not a normal behavior and the way how postfix and the SMTP protocol is designed for the delivering client a message is counted as undelivered until the destination responds with a 2xx code since postfix can't write the queue file it won't answer with 2xx
Re: warning: maildrop/33CAC20FBB: error writing BFF19213F8: queue file write error
Am 28.01.2015 um 17:10 schrieb deoren: On 2015-01-28 08:33, li...@rhsoft.net wrote: Am 28.01.2015 um 15:28 schrieb deoren: I searched via Google and via the mailing list archives, but I didn't find a post which matched my specific situation. I see those warnings in the logs when the system goes down for a reboot. Is the mail lost? Should I be using a different approach when rebooting a server running Postfix? Does the client receive an error and it's then up to it to try again? you need to provide the loglines before *and* after that message Thanks, and you're right, I should have included more information. I was attempting to trim the message down to just the relevant portion and trimmed too far. Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: mysql:/etc/postfix/mysql-pfix-no-srs-virtual-mailbox-maps.cf lookup error for fail2ban-l...@example.com Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: C0150213F8: sender_canonical_maps map lookup problem for fail2ban-l...@example.com Jan 27 16:27:56 screech postfix/pickup[1134]: warning: maildrop/D754B212B1: error writing C0150213F8: queue file write error Jan 27 16:27:56 screech postfix/pickup[1134]: C1FCE213F8: uid=0 from=fail2ban I looked further and within the stunnel logs on this box I noted that the connection between this box and the database server wasn't live yet, so that's why the lookup problem for the destination address occurred. I was under the mistaken impression that Postfix would have temporarily accepted/held the mail and tried to perform additional lookup requests before giving up, but evidently I don't have a solid understanding of the intake process. I'll do further research in that area postfix *must not act* that way you can't accept/held something when half of your lookup-tables are not available because they may contain rules to clearly reject a message there is no temporarily accept if you accept a message you issue 250 OK to the sender and after that you have to deliver it or create a bounce which makes you to a backscatter and leads in blacklisting the only sane thing a MTA can do in doubt is *temporary reject* with 4xx and so the sender tries again later
Re: A strange problem when adding DSPAM to Postfix
Am 28.01.2015 um 19:04 schrieb Орхан Ибад-оглы Гасымов: Trying to add DSPAM to my Postfix - Dovecot setup, I came across an interesting situation, maybe someone here had a similar problem before? Here's what happens: Only local mail (i.e. letters sent from one mailbox to another mailbox on my server) is passed through DSPAM. Emails from other servers are received, but no DSPAM headers are inserted in them. And dspam_stats command shows no hits in the second case, while there are hits for the local mail. Did anyone had this type of misconfiguration before? Your help would be highly appreciated! besides that this is the wrong list and dspam is abandonware (http://comments.gmane.org/gmane.mail.spam.dspam.user/19136) asking for a type of misconfiguration without provide configuration is ridiculous http://www.catb.org/esr/faqs/smart-questions.html#beprecise
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 19:38 schrieb srach: I have read the documents for some different Greylisting opportunities for Postfix This built into Postfix http://www.postfix.org/SMTPD_POLICY_README.html#greylist and popular ones http://wiki.policyd.org http://postgrey.schweikert.ch I am not finding a modern comparison of these and a decision point for choosing one to use best in the latest Postfix versions. Many online postings have a comment but they are most for older versions of Postfix. I wonder if Postfix with modern versions is integrating better ideas and to do it all in one? I think maybe that the choice is not just the recommended built in one of Postifx? It depends on the goals? besides that greylisting is harmful in case of large sending clusters not returning with the same IP while re-try a deferred message postscreen can do this more or less as side effect with deep protool tests postscreen_greet_action = enforce postscreen_bare_newline_enable = no postscreen_bare_newline_action = enforce postscreen_pipelining_enable = no postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = no postscreen_non_smtp_command_action = enforce
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 20:21 schrieb srach: 28. Jan 2015 19:17 by wie...@porcupine.org mailto:wie...@porcupine.org: There are good reasons to NOT integrate, and instead use the least-expensive solution before the most-expensive solution. postscreen implements a least-expensive solution that eliminates most of the spambots without even allowing them to talk to a Postfix SMTP server process. Spamassassin and Clamav are most-expensive solutions that should be used only for mail that cannot be stopped via other means. Okay I see that. Don not spend your money unless you have to! So if that is done using Postscreen for some greylisting what option in Postscreen for only greylisting with the depp protocl tests for some domains is there? I am looking but still see no maps for it *none* - read my previous mail and look how most junk is killed long, long, long before any chance to deliver and so you have *no reason* for do yourself the burden of slow down legit delivery for no benefit
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 20:08 schrieb srach: 28. Jan 2015 18:43 by li...@rhsoft.net mailto:li...@rhsoft.net: besides that greylisting is harmful in case of large sending clusters not returning with the same IP while re-try a deferred message postscreen can do this more or less as side effect with deep protool tests Yes I see that opportunity in Postscreen. I do understand the warning for the large clusters. Then I have to be careful for choosing domains I know. For some I care , but for some I do not. honestly with postscreen *without deep protocol tests) and rbl-scoring (DSNBL as well as DNSWL) there is no point for greylisting at all postscreen_dnsbl_ttl = 5m postscreen_dnsbl_threshold = 8 postscreen_dnsbl_action = enforce postscreen_greet_action = enforce postscreen_dnsbl_sites = b.barracudacentral.org=127.0.0.2*7 dnsbl.inps.de=127.0.0.2*7 bl.mailspike.net=127.0.0.2*5 bl.mailspike.net=127.0.0.[10;11;12]*4 dnsbl.sorbs.net=127.0.0.10*8 dnsbl.sorbs.net=127.0.0.5*6 dnsbl.sorbs.net=127.0.0.7*3 dnsbl.sorbs.net=127.0.0.8*2 dnsbl.sorbs.net=127.0.0.6*2 dnsbl.sorbs.net=127.0.0.9*2 zen.spamhaus.org=127.0.0.[10;11]*8 zen.spamhaus.org=127.0.0.[4..7]*6 zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 hostkarma.junkemailfilter.com=127.0.0.2*3 hostkarma.junkemailfilter.com=127.0.0.4*1 hostkarma.junkemailfilter.com=127.0.1.2*1 wl.mailspike.net=127.0.0.[18;19;20]*-2 list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].2*-4 list.dnswl.org=127.0.[0..255].3*-5 hostkarma.junkemailfilter.com=127.0.0.1*-2 _ if you additionally configure a honeypot-backup-MX always responding with 450 if not already blacklisted around 50% of all bots will try the backup MX and never come back to the primary and they ones coming back are waiting some minutes by assuming greylisting and in the meantime many are on RBL's which where not at the first contact postscreen_whitelist_interfaces = !ip-of-backup-mx, static:all But I do not see how to apply Postscreen maps for deep protocol tests only for some domains countries. Does it do this? it can't by design, if it would have such capapbilities it would no longer be a lightweight daemon in front of spmtpd And if there will be more checking with the Spamassassin and Clamav too I think there is good value in all in one policy integration instead of some in Postscreen too. I think that is making some sense? that makes *zero* sense postscreen kills 90% of all junk long before it connects to a expensive smtpd at all, independent of contentfilters that's much more value then pass every connection to limited smtpd and to harm with misconcepts like greylisting
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
maybe you need some numbers why the below config is good and greylisting not needed peak day 2015/01 * postscreen rejects: 9 * spamassassin: 120 * clamav: 15 * delivered mail: 850 that are numbers for a single day Am 28.01.2015 um 20:19 schrieb li...@rhsoft.net: Am 28.01.2015 um 20:08 schrieb srach: 28. Jan 2015 18:43 by li...@rhsoft.net mailto:li...@rhsoft.net: besides that greylisting is harmful in case of large sending clusters not returning with the same IP while re-try a deferred message postscreen can do this more or less as side effect with deep protool tests Yes I see that opportunity in Postscreen. I do understand the warning for the large clusters. Then I have to be careful for choosing domains I know. For some I care , but for some I do not. honestly with postscreen *without deep protocol tests) and rbl-scoring (DSNBL as well as DNSWL) there is no point for greylisting at all postscreen_dnsbl_ttl = 5m postscreen_dnsbl_threshold = 8 postscreen_dnsbl_action = enforce postscreen_greet_action = enforce postscreen_dnsbl_sites = b.barracudacentral.org=127.0.0.2*7 dnsbl.inps.de=127.0.0.2*7 bl.mailspike.net=127.0.0.2*5 bl.mailspike.net=127.0.0.[10;11;12]*4 dnsbl.sorbs.net=127.0.0.10*8 dnsbl.sorbs.net=127.0.0.5*6 dnsbl.sorbs.net=127.0.0.7*3 dnsbl.sorbs.net=127.0.0.8*2 dnsbl.sorbs.net=127.0.0.6*2 dnsbl.sorbs.net=127.0.0.9*2 zen.spamhaus.org=127.0.0.[10;11]*8 zen.spamhaus.org=127.0.0.[4..7]*6 zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 hostkarma.junkemailfilter.com=127.0.0.2*3 hostkarma.junkemailfilter.com=127.0.0.4*1 hostkarma.junkemailfilter.com=127.0.1.2*1 wl.mailspike.net=127.0.0.[18;19;20]*-2 list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].2*-4 list.dnswl.org=127.0.[0..255].3*-5 hostkarma.junkemailfilter.com=127.0.0.1*-2 _ if you additionally configure a honeypot-backup-MX always responding with 450 if not already blacklisted around 50% of all bots will try the backup MX and never come back to the primary and they ones coming back are waiting some minutes by assuming greylisting and in the meantime many are on RBL's which where not at the first contact postscreen_whitelist_interfaces = !ip-of-backup-mx, static:all But I do not see how to apply Postscreen maps for deep protocol tests only for some domains countries. Does it do this? it can't by design, if it would have such capapbilities it would no longer be a lightweight daemon in front of spmtpd And if there will be more checking with the Spamassassin and Clamav too I think there is good value in all in one policy integration instead of some in Postscreen too. I think that is making some sense? that makes *zero* sense postscreen kills 90% of all junk long before it connects to a expensive smtpd at all, independent of contentfilters that's much more value then pass every connection to limited smtpd and to harm with misconcepts like greylisting
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 20:46 schrieb srach: 28. Jan 2015 19:28 by li...@rhsoft.net mailto:li...@rhsoft.net: maybe you need some numbers why the below config is good and greylisting not needed peak day 2015/01 * postscreen rejects: 9 * spamassassin: 120 * clamav: 15 * delivered mail: 850 that are numbers for a single day Okay that is very good! Numbers are good to see. And they make a clear story. Wow that is really good percents. see attached mailgraph So I think I leave alone the greylisting idea and the deep protocol tests. For the later steps of both Spamassassin CLamav, to keep them less expensive too what recomends are there? Still the policyd or the spamc? I am starting to read the documents for these now with new eyes, not wanting the greylisting integrated or not. * spamass-milter with spamd * clamav-milter both are acting before-queue what's no problem given only a small amount of mail make it there and the benefits are that you can tag from let say 5.0 to 7.9 points and reject = 8.0 http://www.postfix.org/MILTER_README.html having that setup since august 2014 for 1200 users replacing the previous Barracuda Networks appliance and the results are great, the server load is zero, it's running stable and no complaints well, there are HELO/PTR-filters and python-spf-policyd in front of the milters too - if would have imagined how well that all works at the end (after a lot of hours for tuning and config) i would own that setup for years now instead a few months I am arriving to a good solution with these ideas. Asking with getting good answers here changes it for the better. I am seeing the documents are like a fat Oxford Dictionary. Many many words with official particular definitions. They are like a book for childs too, that it tells some very simple stories. But to write stories richly someday like Mr. Shakespeare we must have advise from old authors writing some bad books already in the past! :-)
Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?
Am 28.01.2015 um 21:00 schrieb srach: 28. Jan 2015 19:19 by li...@rhsoft.net mailto:li...@rhsoft.net: postscreen_dnsbl_sites = http://b.barracudacentral.org=127.0.0.2*7 http://dnsbl.inps.de=127.0.0.2*7 I see from the example you give that these are I think all DNSBL that are domain name searching only no - a DNSBL/DNSWL is IP-based In the notes I am keeping from reading I see also a saying of good value for reject_rhsbl_client http://dbl.spamhaus.org reject_rhsbl_reverse_client http://dbl.spamhaus.org reject_rhsbl_sender http://dbl.spamhaus.org spamassassin does URIBL anyways adjust the scores and be happy the point si the score-based result it avoids false positives postfix reject_ is asking for troubles How is it to add these to the Postscreen not expensive checking too? these are not postscreen settings these are smtpd settings for clients passing postscreen I do not read in the Postsreen documents any regards rhsbl because it don't make sense there postscreen is the first and lightweight shield in a concept
