Re: smtp_fallback_relay
> > Alternative/additional approach: > > > > smtp_fallback_relay_threshold_time (compare to > > smtp_pix_workaround_threshold_time) > > > > How long a message must be queued before the Postfix SMTP client > > passes the mail to the smtp_fallback_relay. > > A threshold would work, with the default of 0 meaning that the > threshold is disabled. That sounds good. All I want is the machine to put some effort (a few tries) into delivery instead of going "ah, no, give it to the fallback" > My time is very limited, and this feature is simple enough that I > will take a patch for this. OK -- [*] 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, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: introducing mopher, the mail gopher
forgot LDAP support? suomi On 2013-06-14 08:50, Manuel Badzong wrote: Hi, I would like to introduce mail gopher, a new all-in-one, MIT-licensed mail filter. Mopher is designed to be lightweight, modular and extensible, has several unique features and uses a very flexible and customizable configuration syntax that is very similar to the common firewall rule-lists some of us are already familiar with. Mopher can: + tarpit hosts + greylist hosts + greylist based on sender/recipient tuples + greylist based on sender-domain/recipient tuples + auto-whitelist hosts + auto-whitelist based on sender/recipient tuples + auto-whitelist based on sender-domain/recipient tuples + query black- and whitelists + query for SPF records + speak with spamassassin (through spamd) + reject during any protocol stage + act on body-size + count connections by hosts + count failed/successful delivery attempts by hosts + inject headers with all available information + log all available information (in a format of choice) + archive mails Mopher has: + a db-independent data backend + dynamically loadable modules + extensible syntax (by modules) + well structured default logging Mopher supports: + most libmilter features + Berkeley DB + MySQL + libspf2 + PSL (by Mozilla, see http://publicsuffix.org/) Mopher compiles and runs on: + GNU/Linux + NetBSD + FreeBSD Mopher runs on a couple of production servers, I ran the daemon (mopherd) extensively through valgrind and tested it on several occasions with smtp-source. Due to its modular design, package maintainers can split up a large build into several packages and therefore avoid unwanted dependencies. A pkgsrc-package already exists (see pkgsrc-wip) and I'll probably create a Debian-/RPM-package if nobody else does it in the meantime. Mopher ist extensible, hence there are several things that could be added to mopher in the near future: + legacy BDB support + SQLite support + PostgreSQL support + NoSQL archiving support (any backend possible) + DCC support + DKIM verification support + ... Mopher is hosted on GitHub, has a Mailing-List (with some useful configuration examples) and could some day also get a Wiki: + https://github.com/badzong/mopher + https://groups.google.com/group/mopher Thank you all very much for reading and I hope some of you will give it a shot. Cheers, Manuel P.S. Feedback is always welcome; either public or private.
Re: introducing mopher, the mail gopher
On Fri, Jun 14, 2013 at 08:50:42AM +0200, Manuel Badzong wrote: > I would like to introduce mail gopher, a new all-in-one, MIT-licensed > mail filter. How does it relate to Postfix? Postfix already does this with a bit of help. > Mopher can: > + tarpit hosts Bad idea in userspace. Bad idea in practice, you want to get rid of them as fast as possible. > + greylist hosts > + greylist based on sender/recipient tuples > + greylist based on sender-domain/recipient tuples > + auto-whitelist hosts > + auto-whitelist based on sender/recipient tuples > + auto-whitelist based on sender-domain/recipient tuples > + query black- and whitelists > + query for SPF records Normal policy protocol, properly used and tested since years. > + speak with spamassassin (through spamd) SMTP/LMTP proxy. > + reject during any protocol stage Postfix. > + act on body-size Policy. > + count connections by hosts Built-in. > + count failed/successful delivery attempts by hosts fail2ban. What do you want to do with this information? > + inject headers with all available information PREPEND. > + log all available information (in a format of choice) syslog. > + archive mails Not the purpose of a MTA, the MDA is properly capable of doing so. > Mopher has: > + a db-independent data backend Unlikely. The filesystem is a DB, a directory to be exact. > + dynamically loadable modules Exists as patch for Postfix, but not portable enough. > + extensible syntax (by modules) Urgs. > + well structured default logging Postfix does this. > Mopher supports: > + most libmilter features Aha, so no MTA at all. > + Berkeley DB > + MySQL I see no "real" DB. > + libspf2 Nice try. > + PSL (by Mozilla, see http://publicsuffix.org/) What is the use for this? This all is focused on web. > Mopher compiles and runs on: > + GNU/Linux > + NetBSD > + FreeBSD Impressive, not. Bastian -- You canna change the laws of physics, Captain; I've got to have thirty minutes!
Problem using TLS: lost connection after STARTTLS
Hi, currently we are experiencing problems with an incoming SMTP/TLS connection. Remote side is an Ironport device, we are using postfix 2.8.13 on solaris 10. The problem exists only for incoming mails (ironport to postfix), the other direction works fine. It happens for both opportunistic (which cisco calls "preferred") and mandatory TLS. As soon as they switch to plaintext, the mails pass through. The problem exists with both of their and both of our relays. On our side we are using TLS since several years (2005/2006) with a lot of partners (some of them have ironports too) and it is the first time that we have such an issue. So the problem seems to be on their side, but I'd prefer to be sure and ideally give them a hint on what's going wrong here: Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 mail.info] connect from mail.dgverlag.de[145.253.80.6] Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 mail.info] setting up TLS connection from mail.dgverlag.de[145.253.80.6] Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 mail.info] certificate verification failed for mail.dgverlag.de[145.253.80.6]: untrusted issuer /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 mail.info] mail.dgverlag.de[145.253.80.6]: Untrusted: subject_CN=DGVDEX.DGVERLAG.DE, issuer=VR IDENT SSL CA 2011, fingerprint=3D:5A:B2:71:E2:62:07:88:E5:68:BC:AB:85:9A:55:6D Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 mail.info] Untrusted TLS connection established from mail.dgverlag.de[145.253.80.6]: TLSv1 with cipher RC4-SHA (128/128 bits) Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 947731 mail.warning] warning: TLS library problem: 5847:error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm:a_verify.c:146: Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 mail.info] lost connection after STARTTLS from mail.dgverlag.de[145.253.80.6] Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 mail.info] disconnect from mail.dgverlag.de[145.253.80.6] Jun 14 00:31:58 rv-smtpext-201 postfix/smtpd[22673]: [ID 197553 mail.info] connect from mail2.dgverlag.de[145.253.80.47] Jun 14 00:31:58 rv-smtpext-201 postfix/smtpd[22673]: [ID 197553 mail.info] setting up TLS connection from mail2.dgverlag.de[145.253.80.47] Jun 14 00:31:58 rv-smtpext-201 postfix/smtpd[22673]: [ID 197553 mail.info] certificate verification failed for mail2.dgverlag.de[145.253.80.47]: untrusted issuer /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root Jun 14 00:31:58 rv-smtpext-201 postfix/smtpd[22673]: [ID 197553 mail.info] SSL_accept error from mail2.dgverlag.de[145.253.80.47]: -1 Jun 14 00:31:58 rv-smtpext-201 postfix/smtpd[22673]: [ID 947731 mail.warning] warning: TLS library problem: 22673:error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm:a_verify.c:146: Jun 14 00:31:58 rv-smtpext-201 postfix/smtpd[22673]: [ID 197553 mail.info] lost connection after STARTTLS from mail2.dgverlag.de[145.253.80.47] Jun 14 00:31:58 rv-smtpext-201 postfix/smtpd[22673]: [ID 197553 mail.info] disconnect from mail2.dgverlag.de[145.253.80.47] Does the message TLS library problem: 22673:error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm:a_verify.c:146 indicate a problem on our side? Please let me know if you need any further information. Below the log output with debug_peer_list: Jan Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] connect from mail.dgverlag.de[145.253.80.6] Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostname: mail.dgverlag.de ~? 127.0.0.1/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostaddr: 145.253.80.6 ~? 127.0.0.1/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostname: mail.dgverlag.de ~? 10.221.2.37/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostaddr: 145.253.80.6 ~? 10.221.2.37/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostname: mail.dgverlag.de ~? 10.221.2.38/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostaddr: 145.253.80.6 ~? 10.221.2.38/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostname: mail.dgverlag.de ~? 10.198.68.13/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostaddr: 145.253.80.6 ~? 10.198.68.13/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostname: mail.dgverlag.de ~? 10.198.68.14/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_hostaddr: 145.253.80.6 ~? 10.198.68.14/32 Jun 14 11:44:21 rv-smtpext-201 postfix/smtpd[16654]: [ID 197553 mail.info] match_list_match: mail.dgverl
Re: Problem using TLS: lost connection after STARTTLS
Jan P. Kessler: > Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 947731 > mail.warning] warning: TLS library problem: 5847:error:0D0C50A1:asn1 > encoding routines:ASN1_item_verify:unknown message digest > algorithm:a_verify.c:146: > Jun 14 00:31:58 rv-smtpext-201 postfix/smtpd[22673]: [ID 947731 > mail.warning] warning: TLS library problem: 22673:error:0D0C50A1:asn1 > encoding routines:ASN1_item_verify:unknown message digest > algorithm:a_verify.c:146: They use a message digest function that is not available (or ir not turned on) on your side. I'll leave it to Victor or other OpenSSL knowledgeables to find put what message digest type is the problem. Wietse
Re: introducing mopher, the mail gopher
On Fri, Jun 14, 2013 at 12:08:00PM +0200, Bastian Blank wrote: > On Fri, Jun 14, 2013 at 08:50:42AM +0200, Manuel Badzong wrote: > > I would like to introduce mail gopher, a new all-in-one, MIT-licensed > > mail filter. > > How does it relate to Postfix? It's a milter that some people on this list might find useful. > > Mopher can: > > + tarpit hosts > > Bad idea in userspace. So kernel space then? > > + count failed/successful delivery attempts by hosts > > What do you want to do with this information? Whitelisting based on the amount of successfully delivered mails is probably the best example. > > + PSL (by Mozilla, see http://publicsuffix.org/) > > What is the use for this? It helps with domain-based greylisting. There are no simple rules when figuring out the registered part of a fqdn. Petar Bogdanovic
Re: Problem using TLS: lost connection after STARTTLS
On Fri, Jun 14, 2013 at 12:24:39PM +0200, Jan P. Kessler wrote: > currently we are experiencing problems with an incoming SMTP/TLS > connection. Remote side is an Ironport device, we are using postfix > 2.8.13 on solaris 10. Please show "postconf -n". > Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 > mail.info] certificate verification failed for > mail.dgverlag.de[145.253.80.6]: untrusted issuer > /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root Why do you check client certificates? > Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 > mail.info] Untrusted TLS connection established from > mail.dgverlag.de[145.253.80.6]: TLSv1 with cipher RC4-SHA (128/128 bits) Why do you use RC4? This suite usually have a pretty low preference. > Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 947731 > mail.warning] warning: TLS library problem: 5847:error:0D0C50A1:asn1 > encoding routines:ASN1_item_verify:unknown message digest > algorithm:a_verify.c:146: And now openssl gets something it does not like at all. > Please let me know if you need any further information. Below the log > output with debug_peer_list: The documentation tells you to show configs and no verbose lo. Bastian -- I'm frequently appalled by the low regard you Earthmen have for life. -- Spock, "The Galileo Seven", stardate 2822.3
Re: introducing mopher, the mail gopher
On Fri, Jun 14, 2013 at 11:55:27AM +0200, postfix wrote: > forgot LDAP support? Yes. And probably other items too. It's really an open-end list.. Petar Bogdanovic
Re: introducing mopher, the mail gopher
On Fri, Jun 14, 2013 at 12:37:11PM +0200, Petar Bogdanovic wrote: > On Fri, Jun 14, 2013 at 12:08:00PM +0200, Bastian Blank wrote: > > On Fri, Jun 14, 2013 at 08:50:42AM +0200, Manuel Badzong wrote: > > > I would like to introduce mail gopher, a new all-in-one, MIT-licensed > > > mail filter. > > How does it relate to Postfix? > It's a milter that some people on this list might find useful. So it only supports what the milter server can do. > > > Mopher can: > > > + tarpit hosts > > Bad idea in userspace. > So kernel space then? A milter can't do that anyway, the communication is controlled by the other side of the milter connection. You can wait a long time for each response, but this does not get you anything. > > > + count failed/successful delivery attempts by hosts > > What do you want to do with this information? > Whitelisting based on the amount of successfully delivered mails is > probably the best example. You need whitelisting for high volume senders, because they split stuff over larger address ranges. Those also produce a high rejection rate (not: ratio). > > > + PSL (by Mozilla, see http://publicsuffix.org/) > > What is the use for this? > It helps with domain-based greylisting. There are no simple rules when > figuring out the registered part of a fqdn. So you do greylisting based on DNS reverse lookups? Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4
Re: introducing mopher, the mail gopher
Bastian Blank skrev den 2013-06-14 12:08: + PSL (by Mozilla, see http://publicsuffix.org/) What is the use for this? This all is focused on web. patch postfix to not accept mails with dns A/ records, there is ignorants everywhere -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: Problem using TLS: lost connection after STARTTLS
>> Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 >> mail.info] certificate verification failed for >> mail.dgverlag.de[145.253.80.6]: untrusted issuer >> /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > Why do you check client certificates? Because we authenticate/whitelist some other systems by their client certificate. >> Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 >> mail.info] Untrusted TLS connection established from >> mail.dgverlag.de[145.253.80.6]: TLSv1 with cipher RC4-SHA (128/128 bits) > Why do you use RC4? This suite usually have a pretty low preference. It is the remote side, that tries RC4. If we establish a connection to their ironport, the following is used: Jun 14 11:48:17 rv-smtpext-101 postfix-OUT/smtp[25604]: [ID 197553 mail.info] Untrusted TLS connection established to mail1.dgverlag.de[145.253.80.6]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits) >> Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 947731 >> mail.warning] warning: TLS library problem: 5847:error:0D0C50A1:asn1 >> encoding routines:ASN1_item_verify:unknown message digest >> algorithm:a_verify.c:146: > And now openssl gets something it does not like at all. > >> Please let me know if you need any further information. Below the log >> output with debug_peer_list: > The documentation tells you to show configs and no verbose lo. Bastian, I really don't want to argue here. It is absolutely clear, that (as you and others also have noticed) openssl "does not like sth at all" here. And I doubt that "postconf -n" will help with this, but for the sake of clarity you'll find the information below. What I really wanted to know is, what exactly "openssl does not like at all" (means what kind of message digest is failing here and how we might circumvent/exclude the problem). postconf -n | sed 's/mydomain/EXAMPLE.COM/g' address_verify_map = btree:$data_directory/VERIFY_ADDRESS address_verify_negative_cache = yes address_verify_negative_expire_time = 3d address_verify_negative_refresh_time = 3h address_verify_poll_count = 3 address_verify_poll_delay = 6 address_verify_positive_expire_time = 31d address_verify_positive_refresh_time = 7d address_verify_sender = postmas...@example.com address_verify_transport_maps = btree:/etc/postfix/verify_transport alias_database = hash:/etc/postfix/aliases alias_maps = $alias_database alternate_config_directories = /etc/postfix/OUT, /etc/postfix/TLSONLY body_checks = pcre:/etc/postfix/body_checks body_checks_size_limit = 512000 bounce_queue_lifetime = 3d bounce_template_file = /etc/postfix/bounce.cf command_directory = /opt/vrnetze/postfix/sbin config_directory = /etc/postfix daemon_directory = /opt/vrnetze/postfix/libexec data_directory = /var/spool/postfix/DATA debug_peer_level = 2 default_privs = nobody delay_warning_time = 12h disable_vrfy_command = yes fast_flush_domains = $relay_domains header_checks = pcre:/etc/postfix/header_checks html_directory = no inet_interfaces = all luser_relay = g_vrnetze_cna...@example.com mail_name = Mailservice mail_owner = postfix mailbox_size_limit = 5601 mailq_path = /usr/bin/mailq manpage_directory = /opt/vrnetze/postfix/man maximal_queue_lifetime = 3d message_size_limit = 5600 mime_header_checks = pcre:/etc/postfix/mime_header_checks mydestination = $myhostname, localhost.$mydomain mydomain = EXAMPLE.COM myhostname = mail.EXAMPLE.COM mynetworks = /etc/postfix/relay_from_networks myorigin = $myhostname newaliases_path = /usr/bin/newaliases plaintext_reject_code = 554 proxy_interfaces = 91.235.236.6, 91.235.236.7, 91.235.236.8, 91.235.236.9 queue_directory = /var/spool/postfix readme_directory = /opt/vrnetze/postfix/doc receive_override_options = no_address_mappings relay_domains = $config_directory/relay_to_domains remote_header_rewrite_domain = domain.invalid sample_directory = /etc/postfix sender_canonical_maps = btree:/etc/postfix/sender_canonical sendmail_path = /usr/lib/sendmail setgid_group = postdrop smtp_enforce_tls = no smtp_tls_CAfile = /etc/postfix/CERTS/CAcert.pem smtp_tls_cert_file = /etc/postfix/CERTS/cert.pem smtp_tls_key_file = /etc/postfix/CERTS/key.pem smtp_tls_loglevel = 1 smtp_tls_policy_maps = btree:/etc/postfix/TLS_EMPFAENGER smtp_tls_scert_verifydepth = 8 smtp_tls_session_cache_database = btree:$data_directory/smtp_scache smtp_tls_session_cache_timeout = 3600s smtp_use_tls = yes smtpd_banner = $myhostname ESMTP Mailservice smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce smtpd_end_of_data_restrictions = check_recipient_access btree:/etc/postfix/GROESSENBESCHRAENKUNG smtpd_enforce_tls = no smtpd_helo_required = yes smtpd_policy_service_max_idle = 700s smtpd_policy_service_max_ttl = 1800s smtpd_policy_service_timeout = 600s smtpd_proxy_timeout = 600s smtpd_recipient_restrictions = reject_non_fqdn_recipient, permit_mynetworks, reject_unauth_destination, check_client_access pcre:/etc/postfix/TLS_VERSENDER_CLIENT
Re: introducing mopher, the mail gopher
On Fri, Jun 14, 2013 at 12:48:51PM +0200, Bastian Blank wrote: > On Fri, Jun 14, 2013 at 12:37:11PM +0200, Petar Bogdanovic wrote: > > It's a milter that some people on this list might find useful. > > So it only supports what the milter server can do. Mopher is a milter (or mail filter) and the original mail never described it as being anything else than a milter (e.g. an MTA). > > So kernel space then? > > A milter can't do that anyway, It was a rhetorical question since I wasn't sure what you were saying. > > It helps with domain-based greylisting. There are no simple rules when > > figuring out the registered part of a fqdn. > > So you do greylisting based on DNS reverse lookups? In that particular case, mopher doesn't need to do any lookups but uses whatever libmilter provides as sender hostname (which, at least in case of Postfix, should be a PTR RR that matches with the according A RR). It then extracts the registered part with the help of the PSL rule-set. The default greylisting is therefore based on the following triplet: sender domain (the registered part), envelope from and recipient. Petar Bogdanovic
Re: Problem using TLS: lost connection after STARTTLS
On Fri, Jun 14, 2013 at 12:24:39PM +0200, Jan P. Kessler wrote: > Jun 14 10:24:47 rv-smtpext-101 postfix/smtpd[5847]: [ID 197553 > mail.info] mail.dgverlag.de[145.253.80.6]: Untrusted: > subject_CN=DGVDEX.DGVERLAG.DE, issuer=VR IDENT SSL CA 2011, > fingerprint=3D:5A:B2:71:E2:62:07:88:E5:68:BC:AB:85:9A:55:6D Certificate details: $ openssl x509 -md5 -fingerprint -text -in cert.pem MD5 Fingerprint=3D:5A:B2:71:E2:62:07:88:E5:68:BC:AB:85:9A:55:6D Certificate: Data: Version: 3 (0x2) Serial Number: 162 (0xa2) Signature Algorithm: sha256WithRSAEncryption Issuer: C=DE, O=GAD EG, OU=VR IDENT, CN=VR IDENT SSL CA 2011 Validity Not Before: Jul 13 11:18:43 2012 GMT Not After : Aug 13 21:59:59 2013 GMT Subject: C=DE, ST=HESSEN, L=WIESBADEN, O=DEUTSCHER GENOSSENSCHAFTS-VERLAG EG, OU=ORGANISATION, CN=DGVDEX.DGVERLAG.DE Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:f8:88:4e:bc:7d:3d:73:a7:72:a2:5b:5c:bc:0a: cf:44:10:15:d8:3d:93:1a:35:0d:5f:33:e8:11:53: d0:98:ff:65:89:76:bc:18:d9:0a:62:cb:a5:46:c6: 70:43:aa:6e:11:1a:e8:85:93:51:1f:49:68:c3:72: a8:cd:2f:b3:2d:63:ce:63:67:65:e5:00:5d:4e:8f: 75:56:f3:83:df:ec:84:05:1e:3b:1c:fd:49:97:a7: 22:a9:59:65:f1:74:e3:d5:ce:90:ef:f2:c4:ea:25: 6b:a7:e8:9e:2c:9a:a8:76:a7:b4:9a:54:e8:b3:56: 15:ab:8c:7a:c3:33:62:f2:9c:98:16:35:62:ff:c5: 00:19:06:bd:a2:59:41:40:69:6b:26:e8:c3:86:d0: c0:ed:b0:4e:06:8e:d2:64:7e:2e:cf:03:6b:a9:62: c1:01:fd:7b:d9:1c:48:03:87:35:10:17:9b:0b:f4: 33:98:6d:fe:ea:02:1d:f0:74:1d:e4:b9:be:6d:14: be:61:f0:5f:82:ea:e8:f8:fe:90:84:ed:ac:a3:a3: b9:5c:26:07:e5:68:64:5f:63:69:43:99:9d:ab:cd: a8:26:f6:af:46:32:0a:76:10:2e:b3:a8:e1:bd:63: 9c:56:a5:84:b4:05:cb:11:83:78:73:30:bf:b6:8d: 23:a3 Exponent: 65537 (0x10001) X509v3 extensions: Authority Information Access: OCSP - URI:http://ocsp.vr-ident.de/gtnocsp/OCSPResponder/VR%20Ident%20SSL%20CA%202011 X509v3 Authority Key Identifier: keyid:50:52:4F:44:2E:47:54:4E:2E:45:58:53:53:4C:43:41:2E:53:49:47:47:45:4E:52:53:2E:30:30:30:30:32:32:30:30 DirName:/C=DE/O=GAD EG/OU=VR IDENT/CN=VR IDENT EXTERNAL ROOT CA 2011 serial:04 X509v3 CRL Distribution Points: Full Name: URI:http://www.vr-ident.de/gtncrl/CRLResponder/VR%20Ident%20SSL%20CA%202011 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Subject Key Identifier: 60:1E:93:11:E3:BA:7D:19:A6:88:FB:DD:8E:90:73:50:47:E7:CB:20 X509v3 Extended Key Usage: TLS Web Server Authentication Signature Algorithm: sha256WithRSAEncryption 9b:c5:33:88:de:38:6b:4f:5c:0f:97:af:d7:18:60:f6:7c:03: 23:2b:38:cf:d7:14:fb:31:25:91:61:63:48:cc:52:26:6e:a9: 3a:a0:8f:a7:98:e8:4a:17:8a:e0:fd:a0:d1:56:92:bd:b6:85: 21:02:0f:1c:95:e0:e7:7a:ad:a5:31:21:e9:4b:5f:4a:e3:bd: e7:04:64:54:69:fc:6e:c8:9d:28:ef:53:12:ff:57:c0:71:1e: b7:e8:5a:0a:9d:65:a4:91:2c:1a:d9:36:46:75:c4:56:47:5a: b3:5c:38:7d:4d:ea:12:64:58:8a:3c:02:07:21:53:cc:10:66: 87:5c:63:99:67:04:c0:70:3e:41:62:3f:6a:c0:93:1e:e5:f3: 53:f2:4c:43:b7:b4:83:8f:81:18:a9:42:f2:76:2e:d0:cc:71: bc:ca:66:7b:df:75:73:f1:13:0b:ac:98:ae:92:84:a3:b4:52: 53:b2:00:87:de:1e:cf:cb:d5:a3:32:3c:81:5c:fd:54:e9:c8: 70:b4:b8:d0:64:96:8d:d7:4a:46:f7:2b:b4:df:f7:ad:0c:7d: a6:71:3f:08:7c:7a:a6:9b:c0:38:6c:9b:e6:00:cd:14:4a:bd: 71:6f:c3:a9:87:b9:70:6d:ba:04:59:f1:d8:c7:1d:17:de:6f: 29:e5:3f:1d -BEGIN CERTIFICATE- MIIFAjCCA+qgAwIBAgICAKIwDQYJKoZIhvcNAQELBQAwUDELMAkGA1UEBhMCREUx DzANBgNVBAoMBkdBRCBFRzERMA8GA1UECwwIVlIgSURFTlQxHTAbBgNVBAMMFFZS IElERU5UIFNTTCBDQSAyMDExMB4XDTEyMDcxMzExMTg0M1oXDTEzMDgxMzIxNTk1 OVowgZQxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZIRVNTRU4xEjAQBgNVBAcMCVdJ RVNCQURFTjEsMCoGA1UECgwjREVVVFNDSEVSIEdFTk9TU0VOU0NIQUZUUy1WRVJM QUcgRUcxFTATBgNVBAsMDE9SR0FOSVNBVElPTjEbMBkGA1UEAwwSREdWREVYLkRH VkVSTEFHLkRFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+IhOvH09 c6dyoltcvArPRBAV2D2TGjUNXzPoEVPQmP9liXa8GNkKYsulRsZwQ6puERrohZNR H0low3KozS+zLWPOY2dl5QBdTo91VvOD3+yEBR47HP1Jl6ciqVll8XTj1c6Q7/LE 6iVrp+ieLJqodqe0mlTos1YVq4x6wzNi8pyYFjVi/8UAGQa9ollBQGlrJujDhtDA 7bBOBo7SZH4uzwNrqWLBAf172RxIA4c1EBebC/QzmG3+6gId8HQd5Lm+bRS+YfBf guro+P6QhO2so6O5XCYH5WhkX2NpQ5mdq82oJvavRjIKdhAus6jhvWOcVqWEtAXL EYN4czC/to0jowIDAQABo4IBnzCCAZswZgYIKwYBBQUHAQEEWjBYMFYGCCsGAQUF BzABhkpodHRwOi8vb2NzcC
Semi-OT: Exchange 2013 SMTP Callout
Hello, this is Semi-OT but since a lot of people run Postfix before Exchange I hope to find some knowledge here. Also heads-up :-) We have a couple of Exchange customers behind our frontend MX servers. We don't turn them up until they have configured their HBT servers to reject unknown recipients and we have verified SMTP callout to them. One customer is migrating from Exchange 2007 to Exchange 2013 and it seems to be impossible there. There is some documentation about "Recipient filtering" here: http://technet.microsoft.com/en-us/library/jj218660%28v=exchg.150%29.aspx But it does not work. Until we realized that Exchange started rejecting the recipients, but in DATA stage. mail from: 250 2.1.0 Sender OK rcpt to: 250 2.1.5 Recipient OK data 354 Start mail input; end with . test . 550 5.1.1 User unknown This gets even worse when the mail has two recipients ... doesnotexist@ does not exist, t1@ does... mail from: 250 2.1.0 Sender OK rcpt to: 250 2.1.5 Recipient OK rcpt to: 250 2.1.5 Recipient OK data 354 Start mail input; end with . test . 550 5.1.1 User unknown mail from: 250 2.1.0 Sender OK rcpt to: 250 2.1.5 Recipient OK data 354 Start mail input; end with . test . 250 2.6.0 [InternalId=2740189134859] Queued mail for delivery This is not only unusable for Recipient validation, but will reject legitimate mail since you cannot reject individual recipients in DATA with SMTP. According to this threat: http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/91c26fd2-aa0c-4006-9326-ece609bf4f67/ this is expected. I can hardly believe that. We do not have in-house experience with 2013 yet. Can anyone shed some light at this? Verification against AD (LDAP) would be an option but requires a lot more configuration and coordination with the customer, and some of them are uncomfortable opening those ports anyway. Bernhard
Re: Problem using TLS: lost connection after STARTTLS
Signature Algorithm: sha256WithRSAEncryption It looks your OpenSSL library does not enable this via OpenSSL_add_ssl_algorithms(). The use of certificates with signature algorithms other than MD5 and SHA-1 is supposed to be negotiated via TLSv1.2, plain SSLv3/TLSv1 do not have a way to negotiate these, and clients or servers that use SHA-2 signatures will run into interoperability problems. Can you report the output of "ldd /usr/libexec/postfix/smtpd" (smtpd is in $daemon_directory, adjust as necessary). That will help nail down the exact OpenSSL version in use. Also report the O/S distribution and version of the package that contains the libssl that smtpd depends on. I would have expected SHA-2 support as of OpenSSL 1.0.0a. Ok, so the problem seems to be clear. The system uses an ancient openssl version (sunfreeware package): # uname -a SunOS rv-smtpext-201 5.10 Generic_14-03 sun4v sparc SUNW,T5140 # ldd /opt/vrnetze/postfix/libexec/smtpd libdb-4.7.so => /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so libssl.so.0.9.8 => /usr/local/ssl/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 => /usr/local/ssl/lib/libcrypto.so.0.9.8 libpcre.so.0 => /usr/local/lib/libpcre.so.0 libresolv.so.2 =>/lib/libresolv.so.2 libsocket.so.1 =>/lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libc.so.1 => /lib/libc.so.1 librt.so.1 =>/usr/lib/librt.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libdl.so.1 =>/lib/libdl.so.1 libdevinfo.so.1 => /usr/lib/libdevinfo.so.1 libmp.so.2 =>/lib/libmp.so.2 libmd.so.1 =>/lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libaio.so.1 => /lib/libaio.so.1 libnvpair.so.1 =>/lib/libnvpair.so.1 libsec.so.1 => /lib/libsec.so.1 libgen.so.1 => /lib/libgen.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libavl.so.1 => /lib/libavl.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,T5140/lib/libc_psr.so.1 /platform/SUNW,T5140/lib/libmd_psr.so.1 # /usr/local/ssl/bin/openssl version OpenSSL 0.9.8k 25 Mar 2009 Thank you very much for your help! Is it possible to deactivate the "smtpd_tls_ask_ccert = yes" setting for this special target? Ideally without deactivating the complete STARTTLS extension completely? I understand that the correct solution is an openssl upgrade on our side (due to other security related reasons), but I need a maintenance window for this.
Re: how to stop massive email attack in Postfix
On 14 June 2013 17:44, c cc wrote: > > Hi, > > For the last few days, I noticed that our postfix server had crawl to a halt > due to some kind of email attack. As you can see below, there were a lot of > smtp connections. I was wondering if there is a way to stop this from > Postfix? Thanks! > > /etc/postfix $netstat -plan | grep ':25' | grep ESTAB > tcp0 0 xx.xx.xx.xx:25 181.66.192.196:11798ESTABLISHED > 17329/smtpd > tcp0 0 xx.xx.xx.xx:25 77.42.140.151:54112 ESTABLISHED - > tcp0 0 xx.xx.xx.xx:25 109.166.128.3:36208 ESTABLISHED - > tcp0 0 xx.xx.xx.xx:25 186.46.0.66:16698 ESTABLISHED Presumably they are connecting more than once? Fail2ban? Simon
Re: Problem using TLS: lost connection after STARTTLS
On Fri, Jun 14, 2013 at 05:53:03PM +0200, Jan P. Kessler wrote: > >I would have expected SHA-2 support as of OpenSSL 1.0.0a. > > Ok, so the problem seems to be clear. The system uses an ancient > openssl version (sunfreeware package): > > libssl.so.0.9.8 => /usr/local/ssl/lib/libssl.so.0.9.8 > libcrypto.so.0.9.8 => /usr/local/ssl/lib/libcrypto.so.0.9.8 > > # /usr/local/ssl/bin/openssl version > OpenSSL 0.9.8k 25 Mar 2009 > > Thank you very much for your help! Is it possible to deactivate the > "smtpd_tls_ask_ccert = yes" setting for this special target? Ideally > without deactivating the complete STARTTLS extension completely? Only via NAT, if you can divert traffic from this client IP to a different SMTP listener in which the feature is disabled via master.cf. The sender should replace their certificate, it is not compliant with TLSv1. This too may take time. I never enabled ask_ccert on port 25, I had used 587 for that (on a machine that nevertheless was not an MSA), and clients with special access configured via ccerts had to use a transport table or similar to send to a non-default port to get that access. > I understand that the correct solution is an openssl upgrade on our > side (due to other security related reasons), but I need a > maintenance window for this. Build OpenSSL 1.0.1e from source without shared libraries, just ".a" files (default via OpenSSL's Configure). Then link Postfix against that, and deploy. For example with OpenSSL built in /var/tmp/openssl (libcrypto.a and libssl.a in that directory, and include files in /var/tmp/openssl/include) build as follows (adjusting paths as required): #! /bin/sh DEST=/usr/local CCARGS='-DUSE_TLS -I/var/tmp/openssl/include ...' AUXLIBS='-L/var/tmp/openssl -lssl -lcrypto ...' while read -r name val do CCARGS="$CCARGS $(printf -- '-D%s=\\"%s\\"' $name $val)" done <
Re: how to stop massive email attack in Postfix
On Fri, Jun 14, 2013 at 06:00:37PM +0200, Simon B wrote: > On 14 June 2013 17:44, c cc wrote: > > > > Hi, > > > > For the last few days, I noticed that our postfix server had crawl to a halt > > due to some kind of email attack. As you can see below, there were a lot of > > smtp connections. I was wondering if there is a way to stop this from > > Postfix? Thanks! > > > > /etc/postfix $netstat -plan | grep ':25' | grep ESTAB > > tcp0 0 xx.xx.xx.xx:25 181.66.192.196:11798ESTABLISHED > > 17329/smtpd > > tcp0 0 xx.xx.xx.xx:25 77.42.140.151:54112 ESTABLISHED - > > tcp0 0 xx.xx.xx.xx:25 109.166.128.3:36208 ESTABLISHED - > > tcp0 0 xx.xx.xx.xx:25 186.46.0.66:16698 ESTABLISHED > > Presumably they are connecting more than once? Fail2ban? Looks more like a botnet, so the connections may not in fact recur. I would consider disabling reverse DNS resolution under stress. Anything that reduces latency in the SMTP server. Also make sure recipient lookups are fast (SAV and RAV may lead to concurrency spikes, try to have static sources of recipient information). Also raise the number of smtpd(8) processes. The postscreen(8) feature may help, but this is best with Postfix 2.10.0 or so. -- Viktor.
Re: Semi-OT: Exchange 2013 SMTP Callout
On Fri, 14 Jun 2013 17:10:16 +0200, Bernhard Schmidt wrote: > This gets even worse when the mail has two recipients > ... doesnotexist@ does not exist, t1@ does... > > mail from: > 250 2.1.0 Sender OK > rcpt to: > 250 2.1.5 Recipient OK > rcpt to: > 250 2.1.5 Recipient OK > data > 354 Start mail input; end with . > test > . > 550 5.1.1 User unknown quick and rough work-around might be smtp_destination_recipient_limit = 1 for the Postfix before E-2013. > According to this threat: > > http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/91c26fd2-aa0c-4006-9326-ece609bf4f67/ > > this is expected. I can hardly believe that. Unbelievable... it's harmful threat X-(. pgpgP66rgsAdP.pgp Description: PGP signature
Re: how to stop massive email attack in Postfix
Am 14.06.2013 18:00, schrieb Simon B: > On 14 June 2013 17:44, c cc wrote: >> >> Hi, >> >> For the last few days, I noticed that our postfix server had crawl to a halt >> due to some kind of email attack. As you can see below, there were a lot of >> smtp connections. I was wondering if there is a way to stop this from >> Postfix? Thanks! >> >> /etc/postfix $netstat -plan | grep ':25' | grep ESTAB >> tcp0 0 xx.xx.xx.xx:25 181.66.192.196:11798ESTABLISHED >> 17329/smtpd >> tcp0 0 xx.xx.xx.xx:25 77.42.140.151:54112 ESTABLISHED - >> tcp0 0 xx.xx.xx.xx:25 109.166.128.3:36208 ESTABLISHED - >> tcp0 0 xx.xx.xx.xx:25 186.46.0.66:16698 ESTABLISHED > > Presumably they are connecting more than once? Fail2ban? > > Simon > if you have a massive bot problem , fail2ban is to slow to help i solved it with an iptables recent rsylog combination sorry only german , but tec stuff should be understandable anyway http://sys4.de/de/blog/2012/12/28/botnets-mit-rsyslog-und-iptables-recent-modul-abwehren/ http://blog.schaal-24.de/?p=1626 but be aware such solutions must be well configured and fit to your setup 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, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Semi-OT: Exchange 2013 SMTP Callout
Bernhard Schmidt: > This gets even worse when the mail has two recipients ... doesnotexist@ > does not exist, t1@ does... > > mail from: > 250 2.1.0 Sender OK > rcpt to: > 250 2.1.5 Recipient OK > rcpt to: > 250 2.1.5 Recipient OK > data > 354 Start mail input; end with . > test > . > 550 5.1.1 User unknown > > mail from: > 250 2.1.0 Sender OK > rcpt to: > 250 2.1.5 Recipient OK > data > 354 Start mail input; end with . > test > . > 250 2.6.0 [InternalId=2740189134859] Queued mail for delivery > > This is not only unusable for Recipient validation, but will reject > legitimate mail since you cannot reject individual recipients in DATA > with SMTP. That is really awful. Your gateway will need to use smtp_recipient_limit=1 for all inbound mail (whether a RAV probe message or not). As for people who have to expose their Exchange 2013 server to the Internet there is no such workaround. Wietse
postscreen log lines reporting warnings and fatal errors
wrt: mail_version = 2.10.0
I am trying to understand the cause/causes of these log lines:
1) postfix/postscreen[]: fatal: error [-30986] seeking
/var/lib/postfix/postscreen_cache.db: Success
2) postfix/master[4070]: warning: process
/usr/libexec/postfix/postscreen pid 4366 exit status 1
3) postfix/master[4070]: warning: /usr/libexec/postfix/postscreen: bad
command startup -- throttling
As in the context of these log lines:
Jun 14 12:40:47 mg08 postfix/postscreen[4366]: CONNECT from
[92.56.112.84]:1297 to [198.133.182.99]:25
Jun 14 12:40:47 mg08 postfix/postscreen[4366]: fatal: error [-30986]
seeking /var/lib/postfix/postscreen_cache.db: Success
Jun 14 12:40:47 mg08 postfix/dnsblog[4328]: addr 92.56.112.84 listed
by domain bl.spamcop.net as 127.0.0.2
Jun 14 12:40:47 mg08 postfix/dnsblog[4327]: addr 92.56.112.84 listed
by domain b.barracudacentral.org as 127.0.0.2
Jun 14 12:40:47 mg08 postfix/dnsblog[4329]: addr 92.56.112.84 listed
by domain dnsbl.sorbs.net as 127.0.0.6
Jun 14 12:40:48 mg08 postfix/master[4070]: warning: process
/usr/libexec/postfix/postscreen pid 4366 exit status 1
Jun 14 12:40:51 mg08 postfix/postscreen[4367]: CONNECT from
[5.46.134.65]:30669 to [198.133.182.99]:25
Jun 14 12:40:51 mg08 postfix/postscreen[4367]: fatal: error [-30986]
seeking /var/lib/postfix/postscreen_cache.db: Success
Jun 14 12:40:51 mg08 postfix/dnsblog[4330]: addr 5.46.134.65 listed by
domain b.barracudacentral.org as 127.0.0.2
Jun 14 12:40:52 mg08 postfix/master[4070]: warning: process
/usr/libexec/postfix/postscreen pid 4367 exit status 1
Jun 14 12:40:55 mg08 postfix/postscreen[4368]: CONNECT from
[216.211.163.156]:36611 to [198.133.182.99]:25
Jun 14 12:40:55 mg08 postfix/postscreen[4368]: fatal: error [-30986]
seeking /var/lib/postfix/postscreen_cache.db: Success
Jun 14 12:40:56 mg08 postfix/master[4070]: warning: process
/usr/libexec/postfix/postscreen pid 4368 exit status 1
Jun 14 12:40:56 mg08 postfix/postscreen[4369]: CONNECT from
[190.254.19.122]:18185 to [198.133.182.99]:25
Jun 14 12:40:56 mg08 postfix/postscreen[4369]: fatal: error reading
/var/lib/postfix/postscreen_cache.db: Unknown error
18446744073709520630
Jun 14 12:40:57 mg08 postfix/master[4070]: warning: process
/usr/libexec/postfix/postscreen pid 4369 exit status 1
Jun 14 12:40:57 mg08 postfix/master[4070]: warning:
/usr/libexec/postfix/postscreen: bad command startup -- throttling
The #1 line is confusing in having both the words "fatal" and
"Success". It seems I have seen that discussed in the group before,
(before I installed 2.10.0) but Google is not helping me find the discussion.
All these lines seem to be related to the cases of others who
have reported such errors associated to multiple postscreen processes.
In so far as I understand I do not think I have multiple postscreen processes.
I do recognize that I have 4 ethernet interfaces. eth0 which faces toward the
Internet. eth1 that faces toward CNM internal network. eth2 which is dedicated
to an interface to a filer system (not used by email). lo loopback.
Because I have no code in master.cf to address these interfaces, I think I
am not running multiple postscreen processes.
Here are the uncommented lines of the master.cf:
[root@mg08 log]# cat /etc/postfix/master.cf | grep -v "^#"
smtp inet n - - - 1 postscreen
smtpd pass - - - - - smtpd
dnsblog unix - - - - 0 dnsblog
pickupfifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
rewrite unix - - - - - trivial-rewrite
bounceunix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verifyunix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scacheunix - - - - 1 scache
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp unix -
Re: postscreen log lines reporting warnings and fatal errors
Robert Lopez:
> I am trying to understand the cause/causes of these log lines:
>
> 1) postfix/postscreen[]: fatal: error [-30986] seeking
> /var/lib/postfix/postscreen_cache.db: Success
Your Berkeley DB is screwed up.
Code fragment from src/util/dict_db.c:
/*
* Database lookup.
*/
status =
dict_db->cursor->c_get(dict_db->cursor, &db_key, &db_value,
db_function);
if (status != 0 && status != DB_NOTFOUND)
msg_fatal("error [%d] seeking %s: %m", status, dict_db->dict.name);
Did you build Postfix yourself or is this a package?
Wietse
problem sending some email from mailman
Hey All, Please excuse my loose terminology in the following description as I barely know what I'm doing. I have a strange problem where I'm unable to send some mail from mailman using a postfix installation on the same host. I have postfix mail_version 2.8.4 I have users authenticating and sending mail no problem. I have mailing lists set-up and working no problem. We have our dsl through verizon with a static ip and we have been relaying our mail through outgoing.verizon.net. I tried to send 1662 emails which did not send and are currently waiting in mailman/qfiles/retry. I think what happened is verizon said no way and rejected all the emails. Here is the error that is being generated by the emails waiting to be sent Jun 14 17:00:16 services postfix/smtpd[28663]: NOQUEUE: reject: RCPT from localhost[::1]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Jun 14 17:00:27 services postfix/smtpd[28663]: NOQUEUE: reject: RCPT from localhost[::1]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Jun 14 17:00:38 services postfix/smtpd[28663]: NOQUEUE: reject: RCPT from localhost[::1]: 554 5.7.1 : Relay access denied; from=
Re: problem sending some email from mailman
On 06/14/2013 11:08 PM, Ben Greenfield wrote: Hey All, Please excuse my loose terminology in the following description as I barely know what I'm doing. I have a strange problem where I'm unable to send some mail from mailman using a postfix installation on the same host. I have postfix mail_version 2.8.4 I have users authenticating and sending mail no problem. I have mailing lists set-up and working no problem. We have our dsl through verizon with a static ip and we have been relaying our mail through outgoing.verizon.net. I tried to send 1662 emails which did not send and are currently waiting in mailman/qfiles/retry. I think what happened is verizon said no way and rejected all the emails. Here is the error that is being generated by the emails waiting to be sent Jun 14 17:00:16 services postfix/smtpd[28663]: NOQUEUE: reject: RCPT from localhost[::1]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Your postfix server is refusing to relay mail for this domain. This means the client is not in mynetworks, or did not AUTH, or the destination is not in relay_domains. I know that the reverse lookup for my mail server is currently incorrect. I'm waiting for the update to be made and trying to make sure it is not something else. It is not that to begin with; no external sources are involved. Is that the problem? Nope. YOUR postfix server is refusing to relay mail to those destinations. While reading the table in the SMTPD_ACCESS_README on the website I don't find an exact match RCPT from only RCPT TO int eh Effect of Reject column. I could not parse that. I guess the first question is once my reverse dns is corrected will my mail likely work? Definitely not, as the problem is not related to it. Any other insight that can be shed on any of the above would be appreciated. As mentioned when you joined this list, please provide the output of postconf -n, and the logs for at least one entire message, not just some snippet. -- J.
Re: how to stop massive email attack in Postfix
Simon B skrev den 2013-06-14 18:00: /etc/postfix $netstat -plan | grep ':25' | grep ESTAB tcp0 0 xx.xx.xx.xx:25 181.66.192.196:11798 ESTABLISHED 17329/smtpd tcp0 0 xx.xx.xx.xx:25 77.42.140.151:54112 ESTABLISHED - tcp0 0 xx.xx.xx.xx:25 109.166.128.3:36208 ESTABLISHED - tcp0 0 xx.xx.xx.xx:25 186.46.0.66:16698 ESTABLISHED Presumably they are connecting more than once? Fail2ban? no logs, no problem, if he wants help he could start showing postconf -n -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: postscreen log lines reporting warnings and fatal errors
On Fri, Jun 14, 2013 at 3:09 PM, Wietse Venema wrote:
> Robert Lopez:
>> I am trying to understand the cause/causes of these log lines:
>>
>> 1) postfix/postscreen[]: fatal: error [-30986] seeking
>> /var/lib/postfix/postscreen_cache.db: Success
>
> Your Berkeley DB is screwed up.
>
> Code fragment from src/util/dict_db.c:
>
> /*
> * Database lookup.
> */
> status =
> dict_db->cursor->c_get(dict_db->cursor, &db_key, &db_value,
> db_function);
> if (status != 0 && status != DB_NOTFOUND)
> msg_fatal("error [%d] seeking %s: %m", status, dict_db->dict.name);
>
> Did you build Postfix yourself or is this a package?
>
> Wietse
It was built from postfix-2.10.0.tar.gz, from Porcupine.
--
Robert Lopez
Unix Systems Administrator
Central New Mexico Community College (CNM)
525 Buena Vista SE
Albuquerque, New Mexico 87106
STARTTLS not announced?!
Hi everyone, I just setup postfix on my server but I'm having a problem with TLS. I have TLS configured, there are no errors in the log, but the server does not announce TLS support.Here is the output relevant output from 'postconf -n', the full output is at the end of the message: --- smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtpd_banner = $myhostname ESMTP smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination smtpd_tls_CAfile = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = encrypt smtpd_use_tls = yes - Like I saidthe server does not announce STARTTLS: --- tantalum@3antar ~ % telnet sahara-sweets.com 25 Trying 176.58.120.55... Connected to sahara-sweets.com. Escape character is '^]'. 220 circuitsofimagination.com ESMTP EHLO test.com 250-circuitsofimagination.com 250-PIPELINING 250-SIZE 10485760 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN QUIT 221 2.0.0 Bye Connection closed by foreign host. --- Thanks everyone for their help.If there is any info that will help solving this issue I'd be happy to provide it. full output form postconf: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 header_checks = regexp:/etc/postfix/header_checks home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailbox_size_limit = 1073741824 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 10485760 mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mydomain = circuitsofimagination.com myhostname = circuitsofimagination.com mynetworks = 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.9.6/README_FILES sample_directory = /usr/share/doc/postfix-2.9.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtpd_banner = $myhostname ESMTP smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination smtpd_tls_CAfile = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = encrypt smtpd_use_tls = yes unknown_local_recipient_reject_code = 550 virtual_alias_maps = mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf virtual_gid_maps = static:89 virtual_mailbox_base = /var/mail/vhosts virtual_mailbox_domains = mysql:/etc/postfix/sql/mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf virtual_minimum_uid = 89 virtual_uid_maps = static:89 Nabil Alsharif.
Re: 550 Action not taken
Ravindra Gupta // Viva skrev den 2013-06-13 21:02: So how we will resolve the issue. Please let me know for your valuable suggestion. http://www.postfix.org/ADDRESS_VERIFICATION_README.html#Recipient address verification frontend accept and bounce problems -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: 550 Action not taken
wie...@porcupine.org skrev den 2013-06-13 21:32: Ravindra Gupta // Viva: Jun 12 20:29:27 ems31 postfix/smtp[1816]: CC78D22400E: to=, relay=imap.eemail.example.com[10.0.0.125]:25, delay=0.86, delays=0.01/0/0.42/0.42, dsn=5.0.0, status=bounced (host imap.eemail.example.com[10.0.0.125] said: 550 Action not taken (in reply to end of DATA command)) reject is only good if content filter is before queue is it dovecot reject ? (vacation reject or quotas?) Wietse: Are your SMTP connections intercepted by an anti-virus system? With this I meant an anti-virus system near your Postfix mail system that is blocking mail. Presumably, you are in a better position than me to find out if that is the case. If the mail is rejected by or near the receiving mail server, then that is no longer a question about Postfix. Instead the question is about why they reject your mail. after queue filters and reject is not the solution -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: postscreen log lines reporting warnings and fatal errors
Robert Lopez:
> 1) postfix/postscreen[]: fatal: error [-30986] seeking
> /var/lib/postfix/postscreen_cache.db: Success
Wietse:
> Your Berkeley DB is screwed up.
>
> Code fragment from src/util/dict_db.c:
>
> status =
> dict_db->cursor->c_get(dict_db->cursor, &db_key, &db_value,
> db_function);
> if (status != 0 && status != DB_NOTFOUND)
> msg_fatal("error [%d] seeking %s: %m", status, dict_db->dict.name);
>
> Did you build Postfix yourself or is this a package?
Robert Lopez:
> It was built from postfix-2.10.0.tar.gz, from Porcupine.
Then, you made a mistake. Most likely you have multiple copies of
Berkeley DB on the same system and now have Berkeley DB DLL hell.
My advice is to avoid installing multiple Berkeley DB copies, and
to use the Berkeley DB that comes with the operating system.
Wietse
Re: STARTTLS not announced?!
Nabil Alsharif skrev den 2013-06-15 01:57: please disable html smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtp_ is for sending smtpd_banner = $myhostname ESMTP smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination smtpd_tls_CAfile = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_auth_only = yes this disable starttls since we already is using ssl/tls now smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = encrypt smtpd_use_tls = yes -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: STARTTLS not announced?!
Nabil Alsharif: > Hi everyone, > > I just setup postfix on my server but I'm having a problem with TLS. I > have TLS configured, there are no errors in the log, but the server does > not announce TLS support.Here is the output relevant output from > 'postconf -n', the full output is at the end of the message: Have you looked at all the warning messages in the maillog file? http://www.postfix.org/DEBUG_README.html#logging Wietse
Re: postscreen log lines reporting warnings and fatal errors
wie...@porcupine.org skrev den 2013-06-15 02:36: My advice is to avoid installing multiple Berkeley DB copies, and to use the Berkeley DB that comes with the operating system. locate postfix/postscreen ldd will show the problem why it fails under gentoo its "ldd /usr/libexec/postfix/postscreen" if its a break its fixed by issueing revdep-rebuild -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: STARTTLS not announced?!
On 06/15/2013 02:38 AM, Benny Pedersen wrote: Nabil Alsharif skrev den 2013-06-15 01:57: please disable html My bad.. smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtp_ is for sending Ok so these two options are telling Postfix to check if STARTTLS is offered by the peer and use TLS if available, right? smtpd_banner = $myhostname ESMTP smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination smtpd_tls_CAfile = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_auth_only = yes this disable starttls since we already is using ssl/tls now huh? This part I don't quite understand. How are we disabling TLS? Where was it enabled before? when we said smtp_use_tls = yes? smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = encrypt smtpd_use_tls = yes
Re: STARTTLS not announced?!
On 06/15/2013 02:39 AM, Wietse Venema wrote: Have you looked at all the warning messages in the maillog file? Yes I have, there are no errors or warnings. 'postfix check' doesn't return any warnings or errors either.
Re: STARTTLS not announced?!
On Sat, Jun 15, 2013 at 01:57:12AM +0200, Nabil Alsharif wrote: > I just setup postfix on my server but I'm having a problem with > TLS. I have TLS configured, there are no errors in the log, but > the server does not announce TLS support.Here is the output > relevant output from 'postconf -n', the full output is at the > end of the message: > > smtp_tls_note_starttls_offer = yes > smtp_use_tls = yes smtp_* settings control smtp(8), the SMTP client, so no, those are not relevant to the server's failure to announce STARTTLS. (Also, smtp_use_tls is deprecated, superceded by smtp_tls_security_level.) > smtpd_banner = $myhostname ESMTP > smtpd_recipient_restrictions = permit_mynetworks > reject_unauth_destination Those aren't relevant either. (I'd suggest leaving the default $smtpd_banner setting, however.) > smtpd_tls_CAfile = /etc/pki/dovecot/certs/dovecot.pem > smtpd_tls_auth_only = yes > smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem > smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem I'm no OpenSSL expert, but I'm pretty sure it's wrong to have your own server certificate and key in the same file with your CAs. See TLS_README.html#server_tls for basic server TLS settings. > smtpd_tls_loglevel = 1 > smtpd_tls_security_level = encrypt What? Do you understand what this means? It's not suitable for an Internet mail exchanger, because many sites will not use TLS (TLS isn't required for mail service.) > smtpd_use_tls = yes Deprecated, superceded by smtpd_tls_security_level. > Like I saidthe server does not announce STARTTLS: What you showed us should have announced STARTTLS. I would guess the problem is related to the single file certificate+key+CAs. Since you mentioned upthread that no errors are logged, check your syslogd (try restarting it.) These errors would be logged. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: STARTTLS not announced?!
Nabil Alsharif skrev den 2013-06-15 02:59: smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtp_ is for sending Ok so these two options are telling Postfix to check if STARTTLS is offered by the peer and use TLS if available, right? correct smtpd_banner = $myhostname ESMTP smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination smtpd_tls_CAfile = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_auth_only = yes this disable starttls since we already is using ssl/tls now huh? This part I don't quite understand. How are we disabling TLS? Where was it enabled before? when we said smtp_use_tls = yes? it does not disable tls/ssl, but it removes starttls in plain connection without tls/ssl smtpd vs smtp confusion ? with that setting all smtpd_ clients must use tls or ssl smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = encrypt smtpd_use_tls = yes note here its recieving part of postfix not sending -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: STARTTLS not announced?!
/dev/rob0 skrev den 2013-06-15 03:22: What you showed us should have announced STARTTLS. I would guess the problem is related to the single file certificate+key+CAs. Since you mentioned upthread that no errors are logged, check your syslogd (try restarting it.) These errors would be logged. starttls have nothing to do with self signers -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: STARTTLS not announced?!
Am Samstag, 15. Juni 2013, 03:45:02 schrieb Benny Pedersen: > Nabil Alsharif skrev den 2013-06-15 02:59: > >>> smtpd_tls_auth_only = yes > >> > >> this disable starttls since we already is using ssl/tls now > > > > huh? This part I don't quite understand. How are we disabling TLS? > > Where was it enabled before? when we said smtp_use_tls = yes? > > it does not disable tls/ssl, but it removes starttls in plain > connection without tls/ssl Well, no, it disables AUTH without tls/ssl but not STARTTLS, IIRC. -- MfG Jan
Re: STARTTLS not announced?!
Jan Kohnert skrev den 2013-06-15 03:58: Well, no, it disables AUTH without tls/ssl but not STARTTLS, IIRC. starttls have nothing to do with auth or not auth users can still send plain passwords over unsecured smtpd client connections, starttls just secure there passwords, so tcpdumpers cant see it postfix still anounce auth on port 25 with sasl disabled in main.cf, here i have only sasl on submission / smtps bug ? -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: STARTTLS not announced?!
On Sat, Jun 15, 2013 at 03:45:02AM +0200, Benny Pedersen wrote: > Nabil Alsharif skrev den 2013-06-15 02:59: > > >>> smtp_tls_note_starttls_offer = yes > >>> smtp_use_tls = yes > >> > >>smtp_ is for sending > >Ok so these two options are telling Postfix to check if STARTTLS > >is offered by the peer and use TLS if available, right? > > correct smtp_tls_note_starttls_offer means to note (i.e., log) when a remote server offers STARTTLS. "smtp_use_tls=yes" is the same as (replaced by) "smtp_tls_security_level=may". All of these are covered in the TLS_README.html (except for the deprecated settings, of course.) And none of this is relevant to the $SUBJECT at hand. > >>> smtpd_banner = $myhostname ESMTP > >>> smtpd_recipient_restrictions = permit_mynetworks > >>>reject_unauth_destination > >>> smtpd_tls_CAfile = /etc/pki/dovecot/certs/dovecot.pem > >>> smtpd_tls_auth_only = yes > >> > >>this disable starttls since we already is using ssl/tls now Wrong, Benny. See postconf.5.html#smtpd_tls_auth_only and the correction posted by Jan, with which you tried to argue. > >huh? This part I don't quite understand. How are we > >disabling TLS? We're not. That was wrong. > >Where was it enabled before? when we said smtp_use_tls = yes? That deprecated setting is not relevant. > it does not disable tls/ssl, but it removes starttls in plain > connection without tls/ssl Also wrong. > smtpd vs smtp confusion ? > > with that setting all smtpd_ clients must use tls or ssl With smtpd_tls_security_level=encrypt, yes; not with smtpd_tls_auth_only=yes. Wrong and misleading posts will not help. I think the OP will have to fix the logging problem before we can solve this issue. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: STARTTLS not announced?!
/dev/rob0 skrev den 2013-06-15 05:27: I think the OP will have to fix the logging problem before we can solve this issue. it would be more relative simple to use more default settings, if OP is unsure what to do sorry if i write it such it could be missunderstandelble :( -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: how can I tweak the logging?
Rob Tanner skrev den 2013-06-14 00:18: As requested. I suppose I could grab the queue ID and back track to the sender but when the logs get long (which they do, half a million or more lines) these scans can take a while and I'm trying to capture this info in real time (more or less): big logs can still be grepped, it works well for postfix-logwatch and pflogsumm if you tweek the logs its pointless to grep info from it later, if logs are big, rotate more, eg rotate hourly ? -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
