Re: Test TLS DANE Records
* Viktor Dukhovni postfix-us...@dukhovni.org [2014-05-08 02:09]: On Thu, May 08, 2014 at 01:14:09AM +0200, Sebastian Wiesinger wrote: I published TLS DANE Records for my mailserver and now I am wondering if there is a way to verify that these records are okay/matching the cert. Is there a tool/site where I can test this? I suppose it would be possible with the right openssl s_client commands but I can't figure them out. The records are published for mx.karotte.org if someone wants to try. Postfix 2.11 and 2.12 source tarballs include posttls-finger which will test DANE authentication. http://www.postfix.org/posttls-finger.1.html Your domain's keys are not registered at the .org level. You need to work with your registrar to publish the appropriate DS records. Yes I know, sadly my domain registar doesn't support it right now. But I've put the keys into the ISC DLV registry and my resolver is using that. Looks good to me: posttls-finger: using DANE RR: _25._tcp.mx.karotte.org IN TLSA 3 0 1 8C:63:28:DA:DB:18:FD:46:9C:0F:9D:69:F9:A9:D5:A9:E5:6C:AB:29:F1:6C:76:45:05:EC:03:D6:17:0F:A6:BD posttls-finger: Connected to mx.karotte.org[2a01:4f8:150:7142::25]:25 posttls-finger: 220 mx.karotte.org ESMTP Postfix (Debian/GNU) posttls-finger: EHLO mx.karotte.org posttls-finger: 250-mx.karotte.org posttls-finger: 250-PIPELINING posttls-finger: 250-SIZE 10240 posttls-finger: 250-ETRN posttls-finger: 250-STARTTLS posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250 8BITMIME posttls-finger: STARTTLS posttls-finger: 220 2.0.0 Ready to start TLS posttls-finger: mx.karotte.org[2a01:4f8:150:7142::25]:25: depth=0 matched end entity certificate sha256 digest 8C:63:28:DA:DB:18:FD:46:9C:0F:9D:69:F9:A9:D5:A9:E5:6C:AB:29:F1:6C:76:45:05:EC:03:D6:17:0F:A6:BD posttls-finger: mx.karotte.org[2a01:4f8:150:7142::25]:25: Matched subjectAltName: *.karotte.org posttls-finger: mx.karotte.org[2a01:4f8:150:7142::25]:25: Matched subjectAltName: karotte.org posttls-finger: mx.karotte.org[2a01:4f8:150:7142::25]:25 CommonName *.karotte.org posttls-finger: mx.karotte.org[2a01:4f8:150:7142::25]:25: subject_CN=*.karotte.org, issuer_CN=CAcert Class 3 Root, fingerprint=7B:58:79:56:C2:92:59:35:11:94:79:04:CD:88:93:7B:C4:B6:10:BB, pkey_fingerprint=F1:3F:0E:E9:89:1A:4B:72:90:3D:1A:6B:BB:99:A8:2A:B2:5D:FA:96 posttls-finger: Verified TLS connection established to mx.karotte.org[2a01:4f8:150:7142::25]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: [PATCH 2.11/2.12] connection cache issue correlated with SSL23_GET_SERVER_HELLO:tlsv1 alert decode error?
Hi On 07-05-2014 15:52, wie...@porcupine.org wrote: Viktor Dukhovni: -#define HAVE_NEXTHOP_STATE(state) (STR((state)-iterator-request_nexthop) != 0) +#define HAVE_NEXTHOP_STATE(state) (STR((state)-iterator-request_nexthop)[0] != 0) That is clearly a bug, considering the semantics of the *_NEXTHOP_STATE() primitives: FREE_NEXTHOP_STATE() set iterator-request_nexthop to empty SET_NEXTHOP_STATE() set iterator-request_nexthop to non-empty HAVE_NEXTHOP_STATE() should test if iterator-request_nexthop is non-empty This bug caused plaintext connections for different destinations to be cached under the same lookup key. Thanks to Viktor for finding the cause, to Sahil for discovering that there was a problem, and to myself for structuring Postfix code such that I made this mistake in only one place. Wietse please excuse my ignorance, but the error message in the subject, which i see on my system as well, belongs to a bug in postfix? right? Because i saw the first occurrence on my OpenSuse 13.1 after i got the latest openssl patch. openssl-1.0.1g-11.40.1.x86_64. I want to create a bugreport, but it is good to know for which packet. Thanks in Advance Jörg
Setting the domain name of outgoing e-mail
hi, I have just set up an Ubuntu 14.04 and installed postfix using aptitude install postfix. When I send an e-mail (as root) to a gmail account it arrives from root@localhost I tried to configure it to send as r...@example.com but the only way I managed to make it work isn't really right. In /etc/postfix/main.cf I had myorigin = /etc/mailname and /etc/mailname had example.com in it but that did not help. I tried setting myorigin = example.com and tried myorigin = $mydomain but I still got the mail from root@localhost. The only way I could convince it to send from r...@example.com was to add 162.243.46.210 example.com to the /etc/hosts file. This is not really acceptable as example.com should resolve to another IP address and not to this machine. Am I doing something incorrectly? How could I convince postfix to use the content of mydomain as the domain name when sending e-mail? regards Gabor
RE: Setting the domain name of outgoing e-mail
Try, mydomain = example.com postfix reload Marius. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Gabor Szabo Sent: Thursday, May 8, 2014 2:12 PM To: postfix-us...@cloud9.net Subject: Setting the domain name of outgoing e-mail hi, I have just set up an Ubuntu 14.04 and installed postfix using aptitude install postfix. When I send an e-mail (as root) to a gmail account it arrives from root@localhost I tried to configure it to send as r...@example.com but the only way I managed to make it work isn't really right. In /etc/postfix/main.cf I had myorigin = /etc/mailname and /etc/mailname had example.com in it but that did not help. I tried setting myorigin = example.com and tried myorigin = $mydomain but I still got the mail from root@localhost. The only way I could convince it to send from r...@example.com was to add 162.243.46.210 example.com to the /etc/hosts file. This is not really acceptable as example.com should resolve to another IP address and not to this machine. Am I doing something incorrectly? How could I convince postfix to use the content of mydomain as the domain name when sending e-mail? regards Gabor
Re: [PATCH 2.11/2.12] connection cache issue correlated with SSL23_GET_SERVER_HELLO:tlsv1 alert decode error?
Joerg Rohrer: please excuse my ignorance, but the error message in the subject, which i see on my system as well, belongs to a bug in postfix? right? The bug that was fixed in POSTFIX caused NON-TLS deliveries to reuse the wrong NON-TLS connection. Wietse
Re: Setting the domain name of outgoing e-mail
Thanks, but that did not work either: # hostname dev # hostname -f dev.example.com /etc/hosts: 162.243.46.210 dev.example.com dev [...] main.cf : myorigin = example.com mydomain = example.com myhostname = dev.example.com [...] e-mail arrives from r...@dev.example.com (I even rebooted before sending the e-mail) Gabor On Thu, May 8, 2014 at 2:15 PM, Marius Gologan marius.golo...@gmail.com wrote: Try, mydomain = example.com postfix reload Marius. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Gabor Szabo Sent: Thursday, May 8, 2014 2:12 PM To: postfix-us...@cloud9.net Subject: Setting the domain name of outgoing e-mail hi, I have just set up an Ubuntu 14.04 and installed postfix using aptitude install postfix. When I send an e-mail (as root) to a gmail account it arrives from root@localhost I tried to configure it to send as r...@example.com but the only way I managed to make it work isn't really right. In /etc/postfix/main.cf I had myorigin = /etc/mailname and /etc/mailname had example.com in it but that did not help. I tried setting myorigin = example.com and tried myorigin = $mydomain but I still got the mail from root@localhost. The only way I could convince it to send from r...@example.com was to add 162.243.46.210 example.com to the /etc/hosts file. This is not really acceptable as example.com should resolve to another IP address and not to this machine. Am I doing something incorrectly? How could I convince postfix to use the content of mydomain as the domain name when sending e-mail? regards Gabor
RE: Setting the domain name of outgoing e-mail
Add this too: masquerade_domains = $mydomain -Original Message- From: szab...@gmail.com [mailto:szab...@gmail.com] On Behalf Of Gabor Szabo Sent: Thursday, May 8, 2014 2:27 PM To: Marius Gologan Cc: postfix-us...@cloud9.net Subject: Re: Setting the domain name of outgoing e-mail Thanks, but that did not work either: # hostname dev # hostname -f dev.example.com /etc/hosts: 162.243.46.210 dev.example.com dev [...] main.cf : myorigin = example.com mydomain = example.com myhostname = dev.example.com [...] e-mail arrives from r...@dev.example.com (I even rebooted before sending the e-mail) Gabor On Thu, May 8, 2014 at 2:15 PM, Marius Gologan marius.golo...@gmail.com wrote: Try, mydomain = example.com postfix reload Marius. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Gabor Szabo Sent: Thursday, May 8, 2014 2:12 PM To: postfix-us...@cloud9.net Subject: Setting the domain name of outgoing e-mail hi, I have just set up an Ubuntu 14.04 and installed postfix using aptitude install postfix. When I send an e-mail (as root) to a gmail account it arrives from root@localhost I tried to configure it to send as r...@example.com but the only way I managed to make it work isn't really right. In /etc/postfix/main.cf I had myorigin = /etc/mailname and /etc/mailname had example.com in it but that did not help. I tried setting myorigin = example.com and tried myorigin = $mydomain but I still got the mail from root@localhost. The only way I could convince it to send from r...@example.com was to add 162.243.46.210 example.com to the /etc/hosts file. This is not really acceptable as example.com should resolve to another IP address and not to this machine. Am I doing something incorrectly? How could I convince postfix to use the content of mydomain as the domain name when sending e-mail? regards Gabor
Re: Setting the domain name of outgoing e-mail
Am 08.05.2014 13:26, schrieb Gabor Szabo: Thanks, but that did not work either: # hostname dev # hostname -f dev.example.com /etc/hosts: 162.243.46.210 dev.example.com dev [...] main.cf : myorigin = example.com mydomain = example.com myhostname = dev.example.com [...] e-mail arrives from r...@dev.example.com well, than read your own post myhostname = dev.example.com e-mail arrives from r...@dev.example.com what about fix the sending application to use a full qualified sender instead fight against the result?
Re: [PATCH 2.11/2.12] connection cache issue correlated with SSL23_GET_SERVER_HELLO:tlsv1 alert decode error?
On 08-05-2014 13:21, wie...@porcupine.org wrote: Joerg Rohrer: please excuse my ignorance, but the error message in the subject, which i see on my system as well, belongs to a bug in postfix? right? The bug that was fixed in POSTFIX caused NON-TLS deliveries to reuse the wrong NON-TLS connection. Wietse thank you to both of you for clarification. Regards Jörg
Re: Setting the domain name of outgoing e-mail
Marius, thanks that worked. I am still trying to figure out how this configuration might impact other parts of the service as this machine is supposed to serve a number of domains and a bunch of mailman lists. Gabor On Thu, May 8, 2014 at 2:30 PM, Marius Gologan marius.golo...@gmail.com wrote: Add this too: masquerade_domains = $mydomain
RE: Setting the domain name of outgoing e-mail
That will work for senders that don't have a @doamin.com. If you own multiple domains for which you want to receive messages, you may need: relay_domains = domain1.com domain2.com ... relay_recipient_maps = hash:/etc/postfix/relay_recipients /etc/postfix/relay_recipients @domain1.com x @domain2.com x ... postmap /etc/postfix/relay_recipients postfix reload If you need to deliver the incoming messages to other servers (not local delivery): transport_maps = hash:/etc/postfix/transport /etc/postfix/transport domain1.com smtp:server1.domain1.com domain2.com smtp:server2.domain2.com postmap /etc/postfix/transport postfix reload For all others (relay to external domains - that you don't own) you need to use smtp auth or mynetworks (I prefer first one). Postfix will do the rest. Marius. -Original Message- From: szab...@gmail.com [mailto:szab...@gmail.com] On Behalf Of Gabor Szabo Sent: Thursday, May 8, 2014 2:48 PM To: Marius Gologan Cc: postfix-us...@cloud9.net Subject: Re: Setting the domain name of outgoing e-mail Marius, thanks that worked. I am still trying to figure out how this configuration might impact other parts of the service as this machine is supposed to serve a number of domains and a bunch of mailman lists. Gabor On Thu, May 8, 2014 at 2:30 PM, Marius Gologan marius.golo...@gmail.com wrote: Add this too: masquerade_domains = $mydomain
Re: Setting the domain name of outgoing e-mail
why do you reply off-list? Am 08.05.2014 14:19, schrieb Gabor Szabo: On Thu, May 8, 2014 at 2:30 PM, li...@rhsoft.net wrote: well, than read your own post myhostname = dev.example.com e-mail arrives from r...@dev.example.com http://www.postfix.org/BASIC_CONFIGURATION_README.html#myorigin seems to indicate that what the configuration parameter that sets the outgoing domain is the myorigin variable. Have I misunderstood that part? Nevertheless I commented out the setting of myhostname and even if I only have myorigin = example.com mydomain = example.com you need to understand defaults myhostname is the hostname of the machine which is known at anytime and that is why postfix don't demand you to type it in each and every main.cf postconf -d | grep myhostname I was using the mail command from mailutils. I am not aware of a way to configure it to send with a certain domain name. Though it is not important either, as I was only using it to test the configuration you hardly can test a configuration with the mail-command just because it uses pickup and so not a single smtpd_ setting is applied use a *real* mail client
Re: Setting the domain name of outgoing e-mail
On Thu, May 8, 2014 at 3:29 PM, li...@rhsoft.net li...@rhsoft.net wrote: why do you reply off-list? by mistake. Sorry. Gabor
Re: [PATCH 2.11/2.12] connection cache issue correlated with SSL23_GET_SERVER_HELLO:tlsv1 alert decode error?
On Thu, May 08, 2014 at 12:50:09PM +0200, Joerg Rohrer wrote: Please excuse my ignorance, but the error message in the subject, which I see on my system as well, belongs to a bug in Postfix? Right? No, the TLS error message in the subject is due to a bug in Cisco Ironport email security appliance software versions 8.0 and 8.5. Affected systems should apply the relevant fix from Cisco. https://www.mail-archive.com/openssl-dev@openssl.org/msg34453.html http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa8-0/release_notes/ESA_8-0-1_HP2_Release_Notes.pdf Because I saw the first occurrence on my OpenSuse 13.1 after I got the latest openssl patch. openssl-1.0.1g-11.40.1.x86_64. -- Viktor.
Decrease the Postfix connection speed
Hi there, Is possible to decrease the postfix connection speed in case of possible spam? Per number of connections or messages per second come from a specific IP? BR, Jr.
Re: Decrease the Postfix connection speed
Am 08.05.2014 16:09, schrieb Alfredo Saldanha: Is possible to decrease the postfix connection speed in case of possible spam? Per number of connections or messages per second come from a specific IP? anvil_rate_time_unit= 1800s smtpd_client_connection_rate_limit = 50 smtpd_client_recipient_rate_limit = 400 smtpd_recipient_limit = 100
Re: Decrease the Postfix connection speed
Thanks, I'll check this setup. Junix Am 08.05.2014 16:09, schrieb Alfredo Saldanha: Is possible to decrease the postfix connection speed in case of possible spam? Per number of connections or messages per second come from a specific IP? anvil_rate_time_unit = 1800s smtpd_client_connection_rate_limit = 50 smtpd_client_recipient_rate_limit = 400 smtpd_recipient_limit = 100
Re: Decrease the Postfix connection speed
When the documentation says: IMPORTANT: These limits must not be used to regulate legitimate traffic: mail will suffer grotesque delays if you do so. The limits are designed to protect the smtpd(8) server against abuse by out-of-control clients. How long is this grotesque delays ? Because the idea is not reject or discard the message. Am 08.05.2014 16:09, schrieb Alfredo Saldanha: Is possible to decrease the postfix connection speed in case of possible spam? Per number of connections or messages per second come from a specific IP? anvil_rate_time_unit = 1800s smtpd_client_connection_rate_limit = 50 smtpd_client_recipient_rate_limit = 400 smtpd_recipient_limit = 100
Re: Decrease the Postfix connection speed
Am 08.05.2014 17:26, schrieb Alfredo Saldanha: When the documentation says: IMPORTANT: These limits must not be used to regulate legitimate traffic: mail will suffer grotesque delays if you do so. The limits are designed to protect the smtpd(8) server against abuse by out-of-control clients. How long is this grotesque delays ? Because the idea is not reject or discard the message. you need to adjust this to your mail-flow the values below are active for more than a year on a production server with 160 mail-domains where bulk mail is prohibited in general because if somebody needs newsletter systems this is done here on a own application server with his own MTA and IP Am 08.05.2014 16:09, schrieb Alfredo Saldanha: Is possible to decrease the postfix connection speed in case of possible spam? Per number of connections or messages per second come from a specific IP? anvil_rate_time_unit = 1800s smtpd_client_connection_rate_limit = 50 smtpd_client_recipient_rate_limit = 400 smtpd_recipient_limit = 100
Re: Decrease the Postfix connection speed
Alfredo Saldanha: When the documentation says: IMPORTANT: These limits must not be used to regulate legitimate traffic: mail will suffer grotesque delays if you do so. The limits are designed to protect the smtpd(8) server against abuse by out-of-control clients. As documented these features must not be used to control the flow of LEGITIMATE email. Wietse
Re: Setting the domain name of outgoing e-mail
On Thu, May 8, 2014 at 6:55 PM, /dev/rob0 r...@gmx.co.uk wrote: Nowhere in this thread did you post any logs. So let me show you the real problem, that I need to solve. It seems to be either a Postfix or a Mailman misconfiguration. after Ubuntu 12.04 = 14.04 upgrade I had to reinstall my server that used to run Ubuntu 12.04 and now runs 14.04 Among the pieces that fell apart was mailman handling a bunch of mailing lists and newsletters. If I send an e-mail from my Yahoo account to ga...@hostlocal.com it gets forwarded to my gmail address, so I think the e-mail delivery of Postfix works properly. If I send an e-mail to mail...@hostlocal.com - the message shows up in the archive but it does NOT gets delivered to the subscribers: I see this these two lines in /var/log/mail.log May 8 15:50:28 s8 postfix/smtpd[5603]: NOQUEUE: reject: RCPT from localhost[::1]: 454 4.7.1 szab...@gmail.com: Relay access denied; from=mailman-boun...@hostlocal.com to=szab...@gmail.com proto=ESMTP helo=s8.hostlocal.com May 8 15:50:28 s8 postfix/smtpd[5603]: NOQUEUE: reject: RCPT from localhost[::1]: 454 4.7.1 gabor...@yahoo.com: Relay access denied; from=mailman-boun...@hostlocal.com to=gabor...@yahoo.com proto=ESMTP helo=s8.hostlocal.com May 8 15:50:28 s8 postfix/smtpd[5603]: disconnect from localhost[::1] In another mailing list which is an announcement-only list all the users are moderated, if I send an e-mail the message enters the moderation queue and the sender gets a message from the list that my message is pending. As an administrator I can see the pending message via the web interface, but I don't get e-mail notification about the pending post. When I approve the post it does not get delivered and I see similar error messages as above. Gabor
Re: Setting the domain name of outgoing e-mail
May 8 15:50:28 s8 postfix/smtpd[5603]: NOQUEUE: reject: RCPT from localhost[::1]: 454 4.7.1 szab...@gmail.com: Relay access denied; from=mailman-boun...@hostlocal.com to=szab...@gmail.com proto=ESMTP helo=s8.hostlocal.com Seems like the ipv6 loopback address is not part of mynetworks.
Re: Setting the domain name of outgoing e-mail
Am 08.05.2014 18:02, schrieb Gabor Szabo: On Thu, May 8, 2014 at 6:55 PM, /dev/rob0 r...@gmx.co.uk wrote: Nowhere in this thread did you post any logs. So let me show you the real problem why did you not do that in your inital mail? I had to reinstall my server that used to run Ubuntu 12.04 and now runs 14.04 Among the pieces that fell apart was mailman handling a bunch of mailing lists and newsletters. If I send an e-mail from my Yahoo account to ga...@hostlocal.com it gets forwarded to my gmail address, so I think the e-mail delivery of Postfix works properly. If I send an e-mail to mail...@hostlocal.com - the message shows up in the archive but it does NOT gets delivered to the subscribers: I see this these two lines in /var/log/mail.log May 8 15:50:28 s8 postfix/smtpd[5603]: NOQUEUE: reject: RCPT from localhost[::1]: 454 4.7.1 szab...@gmail.com: Relay access denied; from=mailman-boun...@hostlocal.com to=szab...@gmail.com proto=ESMTP helo=s8.hostlocal.com the client connects with *ipv6* localhost which is ::1 you did not allow that IP to relay the log is really clear and that *all* has *nothing* to do with the subject
Re: Decrease the Postfix connection speed
On Thu, May 08, 2014 at 12:59:03PM -0300, Alfredo Saldanha wrote: Legitimate email is the normal authenticated users, newsletter, or something else, I suppose. Legitimate mail here means *inbound* mail to your MX hosts, from remote sites, that is not known or strongly suspected to be spam. I'd like to put a delay in internal spammers cases. You can apply whatever rate limits you want to *outbound* mail. Because I have today customers that pay to send 3 thousand spams per day. If your customers are spamming, and you don't terminate their access, then you're spamming. -- Viktor.
Re: Decrease the Postfix connection speed
*please* get rid of reply-all on mailing-lists Am 08.05.2014 17:59, schrieb Alfredo Saldanha: Legitimate email is the normal authenticated users, newsletter, or something else, I suppose. I'd like to put a delay in internal spammers cases. Because I have today customers that pay to send 3 thousand spams per day if your customers pay to send 3 thousand spams per day please tell us your IP to blacklist it The idea is let the authenticated user send 300 messages per hour in maximum 3K per 24h. This is in company contract, out of this, I need to increase the delay time to don't punish the regular customers. you can use 'smtpd_client_connection_rate_limit', 'smtpd_client_recipient_rate_limit' and 'smtpd_recipient_limit' with different values for each listeners in master.cf the rest is math When the documentation says: IMPORTANT: These limits must not be used to regulate legitimate traffic: mail will suffer grotesque delays if you do so. The limits are designed to protect the smtpd(8) server against abuse by out-of-control clients. As documented these features must not be used to control the flow of LEGITIMATE email.
Re: Decrease the Postfix connection speed
Hi Viktor, Sorry my ignorance, but this is not inbound messages. This configuration is only to my MSAs servers. Our customers are not spammers, in these cases, we block the user and break the contract, of course. But is not dificult to comes another spammer, because of this I'm trying to configurate this actions. Thank you. - Mensagem original - De: Viktor Dukhovni postfix-us...@dukhovni.org Para: postfix-users@postfix.org Enviadas: Quinta-feira, 8 de maio de 2014 13:10:10 Assunto: Re: Decrease the Postfix connection speed On Thu, May 08, 2014 at 12:59:03PM -0300, Alfredo Saldanha wrote: Legitimate email is the normal authenticated users, newsletter, or something else, I suppose. Legitimate mail here means *inbound* mail to your MX hosts, from remote sites, that is not known or strongly suspected to be spam. I'd like to put a delay in internal spammers cases. You can apply whatever rate limits you want to *outbound* mail. Because I have today customers that pay to send 3 thousand spams per day. If your customers are spamming, and you don't terminate their access, then you're spamming. -- Viktor.
Re: Decrease the Postfix connection speed
Sorry my english. But I mean that they try to do this, but we don't allow, of course. Thank you for your information. - Mensagem original - De: li...@rhsoft.net Para: postfix-users@postfix.org Enviadas: Quinta-feira, 8 de maio de 2014 13:11:37 Assunto: Re: Decrease the Postfix connection speed *please* get rid of reply-all on mailing-lists Am 08.05.2014 17:59, schrieb Alfredo Saldanha: Legitimate email is the normal authenticated users, newsletter, or something else, I suppose. I'd like to put a delay in internal spammers cases. Because I have today customers that pay to send 3 thousand spams per day if your customers pay to send 3 thousand spams per day please tell us your IP to blacklist it The idea is let the authenticated user send 300 messages per hour in maximum 3K per 24h. This is in company contract, out of this, I need to increase the delay time to don't punish the regular customers. you can use 'smtpd_client_connection_rate_limit', 'smtpd_client_recipient_rate_limit' and 'smtpd_recipient_limit' with different values for each listeners in master.cf the rest is math When the documentation says: IMPORTANT: These limits must not be used to regulate legitimate traffic: mail will suffer grotesque delays if you do so. The limits are designed to protect the smtpd(8) server against abuse by out-of-control clients. As documented these features must not be used to control the flow of LEGITIMATE email.
Re: Decrease the Postfix connection speed
On 5/8/2014 11:26 AM, Alfredo Saldanha wrote: Sorry my english. But I mean that they try to do this, but we don't allow, of course. Thank you for your information. Use a policy service such as postfwd to set hourly quotas for your users. http://www.postfix.org/addon.html#policy http://postfwd.org/ -- Noel Jones
Re: Setting the domain name of outgoing e-mail
Jan, thanks for the suggestions. Adding [::1]/128 to mynetworks solved the problem. On Thu, May 8, 2014 at 7:07 PM, li...@rhsoft.net li...@rhsoft.net wrote: Am 08.05.2014 18:02, schrieb Gabor Szabo: So let me show you the real problem why did you not do that in your inital mail? Because originally I did not know if the problem was related to Mailman or to Postfix. It seemed more like a Mailman problem but first I wanted to eliminate the possibility that it was a Postfix issue. That's when I encountered the problem that I actually posted here and first I was hoping to solve the issue that is covered by the title. Gabor
Using check_policy_service for greylisting with sqlgrey
Hi, I'm using postfix-2.10.3 on fedora20 with sqlgrey, distributed across three separate servers through mysql. I've configured it using: check_policy_service inet:127.0.0.1:2501 in main.cf. However, this doesn't provide fault protection in the same way as the greylist.pl example does in the smtpd policy docs describe. The issue is that sqlgrey is a daemon, not a binary that is spawned every time a call is made. Am I understanding it correctly that greylist.pl is run once for every query, or is it okay to have the sqlgrey daemon run from master.cf in the same way? Thanks, Alex
Re: Using check_policy_service for greylisting with sqlgrey
Alex: Hi, I'm using postfix-2.10.3 on fedora20 with sqlgrey, distributed across three separate servers through mysql. I've configured it using: check_policy_service inet:127.0.0.1:2501 in main.cf. However, this doesn't provide fault protection in the same way as the greylist.pl example does in the smtpd policy docs describe. The The Postfix SMTP server uses the same policy daemon connection for multiple queries. issue is that sqlgrey is a daemon, not a binary that is spawned every time a call is made. The policy daemon (running under the Postfix spawn daemon) is started when a Postfix SMTP server connects to its port. The Postfix SMTP server will try to use that connection for several queries. is it okay to have the sqlgrey daemon run from master.cf in the same way? The Postfix spawn daemon assumes that its command will read from standard input, and that it will write to stadard output and standard error. If sqlgrey works that way then it can be run from the Postfix spawn daemon. Otherwise you need a different solution. Wietse
Client side DANE - minimum openssl version
Hi, I'm trying to get client side TLSA/DANE working on a SLES11 SP3 system with openssl 0.9.8j and Postfix 2.11.1. When the smtp client tries to connect to the destination system, the following is logged: May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning: cannot generate TA certificates, no trust-anchor or DANE support May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning: petri-markus.de: dane configured, but no requisite library support May 8 22:23:11 mail postfix-rz-out/smtp[22203]: Untrusted TLS connection established to marge.ceotex.de[2a01:4f8:140:6ffb::24]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) I suspect, that the distributed openssl library is too old, but I may be wrong. Any clues?
Re: Client side DANE - minimum openssl version
On Thu, May 08, 2014 at 10:45:28PM +0200, Markus Petri wrote: I'm trying to get client side TLSA/DANE working on a SLES11 SP3 system with openssl 0.9.8j and Postfix 2.11.1. You need at least OpenSSL 1.0.0. When the smtp client tries to connect to the destination system, the following is logged: May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning: cannot generate TA certificates, no trust-anchor or DANE support May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning: petri-markus.de: dane configured, but no requisite library support May 8 22:23:11 mail postfix-rz-out/smtp[22203]: Untrusted TLS connection established to marge.ceotex.de[2a01:4f8:140:6ffb::24]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) I suspect, that the distributed openssl library is too old, but I may be wrong. You're not wrong, it is too old. -- Viktor.
Re: Client side DANE - minimum openssl version
Am 08.05.2014 22:45, schrieb Markus Petri: openssl 0.9.8j and Postfix 2.11.1. maybe a suboptimal mixture Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Wait if downstream MTA accepts mail - reject if not
Hello, I have some users that forward their mail to GMAIL. This is implemented with virtual alias maps. So postfix forwards: u...@example.com - example.u...@gmail.com The problem is when SPAM mails get through all the postfix defences and get forwarded to GMAIL. GMAIL does some body checks and rejects the mail like this: relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b]:25, delay=3.8, delays=2.7/0.01/0.51/0.6, dsn=5.7.0, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b] said: 552-5.7.0 This message was blocked because its content presents a potential 552-5.7.0 security issue. Please visit 552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to review our 552 5.7.0 message content and attachment content guidelines. f45si10647314eet.279 - gsmtp (in reply to end of DATA command)) Now postfix generates a bounce message which 99.9% of the time will not be deliverable (because sender is faked) and just sit in the queue for five days. Question is, is there a way to prevent this from happening (if possible without using sender verification)? Something like relaying the error back to the client (delay accepting the mail until dowstream MTA has accepted it as well) or not generating a non-delivery notification... I can't figure out if that is possible with postfix. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
RE: Wait if downstream MTA accepts mail - reject if not
Filtering your inbound traffic for spam and malware will prevent these cases (malicious messages will not be forwarded). Marius. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Wiesinger Sent: Friday, May 9, 2014 12:02 AM To: Postfix Users Subject: Wait if downstream MTA accepts mail - reject if not Hello, I have some users that forward their mail to GMAIL. This is implemented with virtual alias maps. So postfix forwards: u...@example.com - example.u...@gmail.com The problem is when SPAM mails get through all the postfix defences and get forwarded to GMAIL. GMAIL does some body checks and rejects the mail like this: relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b]:25, delay=3.8, delays=2.7/0.01/0.51/0.6, dsn=5.7.0, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b] said: 552-5.7.0 This message was blocked because its content presents a potential 552-5.7.0 security issue. Please visit 552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to review our 552 5.7.0 message content and attachment content guidelines. f45si10647314eet.279 - gsmtp (in reply to end of DATA command)) Now postfix generates a bounce message which 99.9% of the time will not be deliverable (because sender is faked) and just sit in the queue for five days. Question is, is there a way to prevent this from happening (if possible without using sender verification)? Something like relaying the error back to the client (delay accepting the mail until dowstream MTA has accepted it as well) or not generating a non-delivery notification... I can't figure out if that is possible with postfix. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: Wait if downstream MTA accepts mail - reject if not
Sebastian Wiesinger: Hello, I have some users that forward their mail to GMAIL. This is implemented with virtual alias maps. So postfix forwards: u...@example.com - example.u...@gmail.com The problem is when SPAM mails get through all the postfix defences and get forwarded to GMAIL. GMAIL does some body checks and rejects the mail like this: It common for people to forward all mail including spam to Gmail, and to discover that some of non-spam mail is not delivered as expected. If you wait for Gmail to reject mail then it is already too late. The solution is do not forward SPAM. Sorry, there is no simple solution. Wietse
Postfix dynamicmaps.cf support
Until now, Debian-style dynamicmaps.cf support has been a chore for downstream maintainers because they needed to patch it into every stable Postfix release. The dynamicmaps.cf feature makes it possible to distribute a minimal version of Postfix, and to provide LDAP, *SQL* etc, support as plugins. The first step to adopting this into Postfix is now approaching completion. Viktor ported the latest Debian-style dynamicmaps.cf support to Postfix 2.12, and I have been working to finish it. The first result, postfix-2.12-20140508-nonprod, can build with Postfix shared libraries (libpostfix-*.so.*) which are a prerequisite for dynamicmaps.cf-style plugins. Platform support is currently limited to Linux, FreeBSD and MacOS X, because that is what we as developers use most. There are minor updates to the Postfix build procedure. To build Postfix with shared libraries: % make makefiles shared=yes ..other arguments.. This will build libpostfix-util.so.2.12-20140508-nonprod etc. files that are by default installed in /usr/local/lib. To change that: % make makefiles shared=yes shlib_directory=/usr/lib ..other arguments.. The above installs the Postfix shared libraries in /usr/lib. % make makefiles shared=yes SHLIB_VERSION=1 ..other arguments.. This results in files named libpostfix-util.so.1 etc. If do not update the Postfix shared library version with each install, then you must stop Postfix before installing a different version. For an introduction see the RELEASE_NOTES, and for more details see the INSTALL file. Wietse
Re: Wait if downstream MTA accepts mail - reject if not
* Wietse Venema wie...@porcupine.org [2014-05-08 23:36]: Sebastian Wiesinger: Hello, I have some users that forward their mail to GMAIL. This is implemented with virtual alias maps. So postfix forwards: u...@example.com - example.u...@gmail.com The problem is when SPAM mails get through all the postfix defences and get forwarded to GMAIL. GMAIL does some body checks and rejects the mail like this: It common for people to forward all mail including spam to Gmail, and to discover that some of non-spam mail is not delivered as expected. I already have RBL checks any other policy in place that prevents most of the SPAM/Malware being accepted, but sometimes Google is more strict / has more advanced filtering it seems. If you wait for Gmail to reject mail then it is already too late. The solution is do not forward SPAM. Sorry, there is no simple solution. Yeah, that was kind of expected. Thanks for the reply anyway. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
RE: Wait if downstream MTA accepts mail - reject if not
RBLs will not protect you against exploited accounts sending malicious emails from popular providers (IPs with good reputation). In your particular case, gmail's rejection might be caused by a .zip file containing .exe or .scr file. Marius. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Wiesinger Sent: Friday, May 9, 2014 1:02 AM To: Postfix Users Subject: Re: Wait if downstream MTA accepts mail - reject if not * Wietse Venema wie...@porcupine.org [2014-05-08 23:36]: Sebastian Wiesinger: Hello, I have some users that forward their mail to GMAIL. This is implemented with virtual alias maps. So postfix forwards: u...@example.com - example.u...@gmail.com The problem is when SPAM mails get through all the postfix defences and get forwarded to GMAIL. GMAIL does some body checks and rejects the mail like this: It common for people to forward all mail including spam to Gmail, and to discover that some of non-spam mail is not delivered as expected. I already have RBL checks any other policy in place that prevents most of the SPAM/Malware being accepted, but sometimes Google is more strict / has more advanced filtering it seems. If you wait for Gmail to reject mail then it is already too late. The solution is do not forward SPAM. Sorry, there is no simple solution. Yeah, that was kind of expected. Thanks for the reply anyway. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: Wait if downstream MTA accepts mail - reject if not
On Fri, May 09, 2014 at 12:01:43AM +0200, Sebastian Wiesinger wrote: I already have RBL checks any other policy in place that prevents most of the SPAM/Malware being accepted, but sometimes Google is more strict / has more advanced filtering it seems. You may also need content-based filters, though those are not perfect either, they should be able to cut the spam volume down further (if you're not already doing that too). -- Viktor.
Re: Postfix dynamicmaps.cf support
On Thu, May 08, 2014 at 05:56:33PM -0400, Wietse Venema wrote:
The first step to adopting this into Postfix is now approaching
completion. Viktor ported the latest Debian-style dynamicmaps.cf
support to Postfix 2.12, and I have been working to finish it.
One thing we need to nail down is the location of the dynamicmaps.cf
file itself.
With Debian this goes into ${config_directory}/dynamicmaps.cf,
which is problematic with multiple instances. There really should
be only one dynamicmaps.cf per system, not per Postfix instance.
The postfix-2.12-20140508-nonprod solution is to put dynamicmaps.cf
into $daemon_directory, which addresses the above issue, but raises
a new one. We now have a volatile system-specific configuration
file that needs to get updated by packages that install new table
drivers that lives in $daemon_directory.
Until not too long ago, I used to maintain multiple Postfix releases
in AFS, and daemon_directory was in read-only AFS storage, it was
the same for all systems with that particular Postfix release. In
other words, daemon-directory was shareable between hosts and could
be mounted read-only.
Adding dynamicmaps.cf to $daemon_directory forces it to be non-shared
and writable by each system. This is also not backwards compatible
with the existing location of the file on Debian.
I had suggested putting dynamicmaps.cf in the compile-time default
configuration directory, which is typically /etc/postfix (no change
for Debian) and is definitely system-specific. I don't recall why
we switched to $daemon_directory, but perhaps we should reconsider?
--
Viktor.
Re: Postfix dynamicmaps.cf support
Viktor Dukhovni: Until not too long ago, I used to maintain multiple Postfix releases in AFS, and daemon_directory was in read-only AFS storage, it was the same for all systems with that particular Postfix release. In other words, daemon-directory was shareable between hosts and could be mounted read-only. postfix-files can be shared because it references files that are shared. dynamicmaps.cf can be shared provided as you ALSO share the dynamicmaps.cf plugins by ALSO putting them into $daemon_directory. These files are not fundamentally different. If there is a difference then they are used incorrectly. Wietse
Re: Using check_policy_service for greylisting with sqlgrey
Hi, On Thu, May 8, 2014 at 3:47 PM, Wietse Venema wie...@porcupine.org wrote: Alex: Hi, I'm using postfix-2.10.3 on fedora20 with sqlgrey, distributed across three separate servers through mysql. I've configured it using: check_policy_service inet:127.0.0.1:2501 in main.cf. However, this doesn't provide fault protection in the same way as the greylist.pl example does in the smtpd policy docs describe. The The Postfix SMTP server uses the same policy daemon connection for multiple queries. issue is that sqlgrey is a daemon, not a binary that is spawned every time a call is made. The policy daemon (running under the Postfix spawn daemon) is started when a Postfix SMTP server connects to its port. The Postfix SMTP server will try to use that connection for several queries. is it okay to have the sqlgrey daemon run from master.cf in the same way? The Postfix spawn daemon assumes that its command will read from standard input, and that it will write to stadard output and standard error. If sqlgrey works that way then it can be run from the Postfix spawn daemon. Otherwise you need a different solution. Okay, I'm seeing that it's possible to configure sqlgrey to listen on a socket, but I can't get that working either. I've configured sqlgrey to listen on the private/greylist socket created by postfix. When configuring master.cf to create a socket: greylist unix - n n - 0 spawn user=nobody argv=/usr/bin/perl /usr/sbin/sqlgrey and adding the check_policy_service to main.cf: check_policy_service unix:private/greylist It responds with: May 8 21:28:01 mail01 postfix/spawn[19944]: warning: command /usr/bin/perl exit status 1 May 8 21:28:01 mail01 postfix/smtpd[19940]: warning: premature end-of-input on private/greylist while reading input attribute name When I run it manually from the command-line, it reports that it's binded successfully to the postfix socket. I'm assuming somehow sqlgrey isn't properly understanding the data format necessary? Yet it communicates properly when only specified as a inet service in main.cf. If the daemon is inaccessible, mail delivery stops, and users receive a connection refused message. Is there any way to configure this to avoid the hard failure, without having to configure the private/greylist service? Thanks, Alex Wietse
Re: Postfix dynamicmaps.cf support
On Thu, May 08, 2014 at 08:13:00PM -0400, Wietse Venema wrote: postfix-files can be shared because it references files that are shared. dynamicmaps.cf can be shared provided as you ALSO share the dynamicmaps.cf plugins by ALSO putting them into $daemon_directory. Yes, that'll work I guess. And the Debian backwards compatibility is not that compelling in this case? -- Viktor.
