Re: TLS errors with GMX/web.de
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.08.2013 11:48, schrieb Sebastian Wiesinger: This error ONLY occurs with their servers. My question is if anyone has an idea what could cause this error. My first guess is that they check certificates for validity and I only have an CACert certificate. Also I would like to know if anyone else sees this on their postfix? Still delivers fine for me (and my mail-server) running Postfix 2.10.1: Received: from mout.web.de (mout.web.de [212.227.15.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.modelnine.org (Postfix) with ESMTPS id 8854E3640A for modeln...@modelnine.org; Tue, 20 Aug 2013 08:35:39 +0200 (CEST) - -- - --- Heiko. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSEz9zAAoJEDMqpHf921/S1/gIAJolkXgx6z8yVWorTK2xG/F5 CbPJLXBgZhtLQg4zkoXPQGhImXGVK8SesH6fW6E8Pb/+PXROPOtmZ5azFjoBwQVX 6ihljFw8dCQxGW12CTSIs4AvYwv2peaGxWMkIufnSg57xl9b/grdbcujoekCZ70l FHFT4ZDlZ3X8V52VrvTolUrA0zA3vmzthuNxEhPY00EeSy5qn7usVhFPOhAcSf5T kwsGnCOo+Fsq8Eejqw4abCGSizO3hWO0tsmqUDo77t8Hp0Pih/yr2jggiwC0F3Xo T+HHGKCQC1ZSZ+4mLRU7tGk4aDEoaEZhMV955Tr6TYT6K7+29QoBXK+2+4Ru4eg= =stXd -END PGP SIGNATURE-
Re: TLS errors with GMX/web.de
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.08.2013 12:12, schrieb Sebastian Wiesinger: * Heiko Wundram modeln...@modelnine.org [2013-08-20 12:09]: Still delivers fine for me (and my mail-server) running Postfix 2.10.1: Received: from mout.web.de (mout.web.de [212.227.15.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.modelnine.org (Postfix) with ESMTPS id 8854E3640A for modeln...@modelnine.org; Tue, 20 Aug 2013 08:35:39 +0200 (CEST) what kind of certificate do you have? Official, selfsigned? I have one from CACert and I wonder if that is the problem... Official certificate by StartSSL on this host, but I'm also getting inbound mail from web.de without problems on other systems that have self-singled certificates and do offer STARTTLS. I'd rather take a guess that your SSL library doesn't advertise a cipher spec that's accepted by the web.de servers (although I wouldn't know about restrictions they impose) - you might also simply want to try and test whether openssl s_client has anything to say about your exposed configuration. Anyway, testing mx.karotte.org from mail.modelnine.org seems to show that the connection should work in principle (I'm getting the same results as to SSL session negotiation as when I'm connecting to my MX): New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 1024 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 except for the fact that my key is 2048 bits, and yours is 1024 bits. - -- - --- Heiko. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSE0PuAAoJEDMqpHf921/SoWoIAJo5Vz2AJv7d2NJr4C6g88se 8Y/ItWFynoYmWuHmYgKYgmtHnLW7WQFq08k0TDrL1SsNJvc2al0T3cNvqEUTnENZ UoTsye0rfg6Zp9TIdj85DmmyBkKjKtMBgaEu+aeXB29CR6g5P1FcWIpNbpu1U+Cg f0pngeVVWGpMZdiCC0cctbROllarFaMQBtX9Cuxw74m92mRkMArDzErsFtB/dc6Z TSJtbb2BmH0uCduAGcBzrzMHHcP6eULIZgubp6gxGSNddlT+jEMPDTj/N2PPj7pi gcWk/Eh5eU/QcyeE7Q2kaZmVf5C7AZ70xD2nPFyDU80XUstKTCYXZM9ylFWMQTE= =PZ2s -END PGP SIGNATURE-
Configuring non-delivery warning messages - timeouts and multiple warning mails?
Hey! My searching through the Postfix documentation didn't turn up anything relevant, so I thought I'd ask on the list: which parameter(s) control whether (and if possible: how many/more than one?) warning messages are sent in the case that a mail can't be delivered for a specified amount of time (due to 400 errors or due to connection failures to the remote MX) but remains in the queue? Thanks for any hint! -- --- Heiko.
Re: Down To One Problem?
Am 23.10.2011 19:13, schrieb Jack Fredrikson:
I may be dreaming, but this could be my last problem with my installation.
After following all your good advice, I still have this one problem and it is
pervasive in all emails:
Oct 23 09:50:58 myserver postfix/pipe[30578]: BB2BB5790262: to=f...@bar.com,
relay=dovecot, delay=12684, delays=12683/0.18/0/0.27, dsn=4.3.0, status=deferred
(temporary failure. Command output: doveconf: Warning: NOTE: You can get a new clean
config file with: doveconf -n dovecot-new.conf doveconf: Warning: Obsolete setting
in /usr/local/etc/dovecot/dovecot.conf:5: imap_client_workarounds=outlook-idle is no
longer necessary doveconf: Warning: Obsolete setting in
/usr/local/etc/dovecot/dovecot.conf:17: add auth_ prefix to all settings inside auth {}
and remove the auth {} section completely doveconf: Warning: Obsolete setting in
/usr/local/etc/dovecot/dovecot.conf:19: passdb pam {} has been replaced by passdb {
driver=pam } doveconf: Warning: Obsolete setting in
/usr/local/etc/dovecot/dovecot.conf:21: userdb passwd {} has been replaced by userdb {
driver=passwd } doveconf: Warning: Obsolete setting in
/usr/local/etc/dovecot/dovecot.conf:23: auth_user
has been replaced by service auth { user } dov
As the error states: this is a dovecot problem. Ask on the dovecot list
(or try to understand the error message... it's all in there).
--
--- Heiko.
Re: First Insallation, Bouncing Emails
Am 21.10.2011 16:52, schrieb Jack Fredrikson: That error appears to come from a file called /etc/postfix/mysql_virtual_alias_maps.cf that has this line: SELECT goto FROM alias WHERE address = ‘%s’ AND active = 1 Therefore, the address has question marks in it. Looks like a hacker, no? No, the quotation marks in that file are broken. Use '' (simple marks), and not some typographic variant of those (i.e., represented as three bytes in UTF-8, which gets logged as ???). -- --- Heiko.
libsrs patch for Postfix
Hey! I'm currently working up a patch for Postfix which implements support for libsrs2 functionality in the Postfix core. I've gotten to some design decisions I'm currently somewhat... undecided about: 1) Rewriting the recipient Basically, rewriting the recipient (in case of a valid SRS address) is a task for trivial-rewrite, as I gather. smtpd and qmgr talk to trivial-rewrite at some point in time, requesting either a rewrite of the address to normal form, or a resolution of the address for mail transport, and I'm not entirely certain where resolution of the recipient to the actual source form should be placed. I'm currently somewhat in favor of placing it in rewrite_tree(), simply because SRS is only a means to obfuscate an address, and the deobfuscation of an address bound for the local srs domain is generally not a transport resolution thing, but just a rewriting, but rewrite_tree() currently does not call out to any maps or such. What would real Postfix developers do? 2) Rewriting the sender This part is finished and working (in the patch I'm currently running on one of my testing mailservers), and is implemented directly in smtp, right after the hook that pipes the smtp sender through generics maps. This means that only the SMTP/LMTP transports receive actual treatment for source rewriting, but there's really nothing more protocol-wise that actually requires SRS. Does this make sense? 3) String lists Is there any API documentation for configuration parameters which are lists of strings, separated by some separator? I currently parse a configuration parameter with strchr() into separate components, but that's error prone, and I guess there's some form of infrastructure that deals with this (for parsing mydestination, etc.). Anyway, if there's interest in the patch, I'll make it available as soon as I fix up the recipient rewriting stuff, and I'd love to get some feedback on the above. Thanks! -- --- Heiko.
Re: Setting different smtpd_sasl_security_options depending on connecting IP
Am 07.09.2011 19:06, schrieb Jeroen Geilman: On 2011-09-06 13:58, Heiko Wundram wrote: Am 06.09.2011 13:42, schrieb Noel Jones: Or use firewall rules to redirect connections from that client to a different port with different smtpd_sasl_security_options. Thanks, after an off-list reply suggesting just that I tried that out, and that works like a charm. Adding the client to mynetworks won't cut it, as I don't trust the system except for the fact that I can control the traffic between the system and the smarthost; authentication is a must so that I can trace whether the host does bad things. You can trace that regardless, since postfix logs what happens. However, only SMTP AUTH combined with smtpd_sender_login_maps and its various restrictions allow you to /control/ what happens. Hooray for the little semantic difference, but I actually meant trace, simply because the target machine is not under my control, and as a terminal server with multiple logins it actually makes a difference whether I allow all clients using it to relay mail (aka. mynetworks), or only a specific client after he/she logs in (in this case the client running the mentioned Java backup software, which sends the mail and for which I need to enable plaintext auth without TLS, ugh). As I stated earlier: I trust the network between the client and the relay, but not the client (or rather, only a part of the client, and I'd like to make sure the relay is conversing with the right part). So, trace was actually semantically correct here (in addition to of course having control, as you said), because with login data given to the client running the software I can clearly lay the blame in case something goes wrong, which I couldn't with mynetworks. ;-) Anyway, a REDIRECT matching the source IP of the client to the plaintext-allowed Postfix instance running on a different port works fine! -- --- Heiko.
Setting different smtpd_sasl_security_options depending on connecting IP
Hey all! As the title says: is there a possibility to set different smtpd_sasl_security_options depending on the connecting IP (or rather subnet) of the client that tries to do authentication? I've looked at the access maps documentation of postfix, but can't see how that relates to setting up different values for this configuration parameter. Thanks for any direction where to look! -- --- Heiko.
Re: Setting different smtpd_sasl_security_options depending on connecting IP
Am 06.09.2011 11:24, schrieb Patrick Ben Koetter: * Heiko Wundrammodeln...@modelnine.org: As the title says: is there a possibility to set different smtpd_sasl_security_options depending on the connecting IP (or rather subnet) of the client that tries to do authentication? No, you can't. Which problem are you trying to solve? Maybe there's another way to do it. Thought so; the problem I'm trying to solve is getting software which is connected via LAN to a mail relay to be able to use the relay. :-) The software (which is a Java-based backup solution) is neither able to use TLS/SSL when using the smarthost to send out its notifications, nor is it able to do any non-plaintext authentication (i.e., only LOGIN), and as such I need to set up smtpd_sasl_security_options = noanonymous to allow the software to function. Security-wise, this is somewhat okay: the server hosting the backup software is connected via MAC/IP-firewalled switches to the mail relays, and as such I'm not too concerned having people eavesdrop on the traffic that's exchanged between the two systems, so that allowing plaintext auth for this specific case even without TLS should be okay. I'm not too happy with that, though, in the general case: the smarthost is also used by external systems to relay, and these should always use either non-TLS with non-plaintext authentication (CRAM-MD5 in the specific case), or use TLS. Enforcing this policy for external users of the mail system was straightforward with different configurations of smtpd_(tls_)sasl_security_options, but now means that I have to rely on the external users to do the right thing because I'm required to allow plaintext auth also for the non-TLS case. Anyway, maybe I'll try to hack together a patch for this if I've got the time to do so, I just wanted to know whether there's the possibility to do this out of the box. Thanks! -- --- Heiko.
Re: Setting different smtpd_sasl_security_options depending on connecting IP
Am 06.09.2011 12:29, schrieb Patrick Ben Koetter: You can offer a different SASL policy on a different port on the Postfix server side. Clone the smtp ... smtpd service line and configure it to listen on a different port e.g. 2525. Then add -o smtpd_sasl_security_options=noanonymous and let the java client connect there. Use a firewall to control access to that port. I've thought of that too, but: not possible, as the software does not allow connecting anywhere else but port 25 for mail relay. ;-) If I don't find the time to try and patch Postfix to offer this functionality, I'll probably attach an additional IP to the relay system which is then firewalled to allow only connections from the local subnet, and attach an additional smtpd process to that specific IP on port 25, which should work. Thanks! -- --- Heiko.
Re: Setting different smtpd_sasl_security_options depending on connecting IP
Am 06.09.2011 13:42, schrieb Noel Jones: Or use firewall rules to redirect connections from that client to a different port with different smtpd_sasl_security_options. Thanks, after an off-list reply suggesting just that I tried that out, and that works like a charm. Adding the client to mynetworks won't cut it, as I don't trust the system except for the fact that I can control the traffic between the system and the smarthost; authentication is a must so that I can trace whether the host does bad things. Thanks for your hints! -- --- Heiko.
Re: blocking supp...@...
On Wed, 22 Jul 2009 10:31:35 -0600, Robert Lopez rlopez...@gmail.com wrote: We get a lot of spam from a marketing company that uses hundreds of ip addresses and hundreds of domain names but it always comes from support at which ever names they are using that day. My supervisor wants me to block all email coming from supp...@*. Uhm, that plan is just plain wrong, sorry. Our ticketing system uses support@ourdomain, which would mean that you'd block all mails that are directed to/from our ticketing system. And I know that quite a lot of other companies use just the same local part for their ticket system(s) (which means that you wouldn't be able to communicate with their support, either), except when you manually whitelist them each time that you find out about one of these incompatabilities. I have concerns about blocking legitimate email. You should have severe concerns in case you implement that kind of block, yes. Unless you don't correspond with _any_ other company (or rather, nobody ever sends you unsolicited, but desired mail), I'd have severe doubts that blocking supp...@* this generally helps you even the slightest bit; you're just replacing one evil with another. Are the marketing emails somewhat related? I.e., could you train a bayesian filter to match and discard them? Or, do they have some kind of reappearing header (apart from the From)? For the former, you could test by training a spambayes* with some ham and some spam (which in this case is the marketing letter[s]), and integrate that into the mail delivery chain using the local delivery agent. I use this method successfully to sort out some recurring chain-mails we receive from one of our suppliers, who doesn't seem to be able to unsubscribe us from his mailings. For the latter, you could use a Header-Check inside the smtpd_end_of_data_restrictions from Postfix. Those would be at least two _sensible_ routes to try, I'd say. * http://spambayes.sourceforge.net/ -- Heiko Wundram Gehrkens.IT GmbH FON 0511-59027953 | http://www.gehrkens.it FAX 0511-59027957 | http://www.xencon.net Gehrkens.IT GmbH Strasse der Nationen 5 30539 Hannover Registergericht: Amtsgericht Hannover, HRB 200551 Geschäftsführer: Harald Gehrkens, Daniel Netzer
Re: Lookup Performance for Postmapped Files
Am Wednesday 10 December 2008 15:52:29 schrieb Fat Bear Mail Services: My virtual_alias_maps file (hash:/etc/postfix/virtual) is many thousands of lines. Does sorting the virtual file before running postmap improve subsequent lookup performance? Just curious. Short answer: no. Long answer: most probably not, because the database backend that is used for the map uses a sort order for the key anyway to have fast lookups. Generally, the database systems I know of (except flat-file databases) use some form of prefix-tree or a hash map to sort the keys for fast searching, and as such the order in the input file does not matter at all, as the keys are reordered anyway when creating the map. -- Heiko Wundram hackerkey://v4sw7CHJLSUY$hw5ln5pr7FOP$ck2ma9u7FL$w3DVWXm0l7GL$i65e6t3EMRSXb7ADORen5a26s5MSr2p-6.62/-6.56g5AORZ
Re: How to have postfix not generate a bounce message when an email is rejected for a specific reason.
Am Wednesday 26 November 2008 18:15:05 schrieb LaGatorVII: snip ... I see two possible solutions, both of which I am not savvy enough to do on my own: 1) Some setting or filter in Postfix to not generate a bounce message when an email is rejected for the above reason. And what about a message being rejected by Exchange because the SPAM filtering has failed (i.e., generated a false positive), being from a correct sender? Refusing delivery (or bouncing) of a message is one thing, silently throwing it away is another. Generally, you'll never, ever want to do this (and it directly violates SMTP protocol and also [at least here in germany] your _legal_ obligations as a mail carrier AFAIK). 2) Some script to delete mail messages via a cron job if they include the above rejection reason. 550 5.7.1 Requested action not taken: message refused. I might be able to figure out a script that can delete the files at the file level but I am not sure what this would do to Postfix. See above. Additionally, even if you only delete bounces after they are n hours old, the bounce recipient might not have been reachable in that time (greylisting with sav comes to mind), so you might also delete good bounces (even though I personally find this approach to be better than the first, but objectionable nevertheless). Please note that the Postfix server is locked down pretty good. All of the helo, sender and recipient restrictions are in place, as well as two RBL filters. It is just that about 25 times per day the Exchange servers are a little better at filtering, and we do not want those extra mails to get through to the users. From what I can tell, your Postfix isn't locked down enough. The implementation we run does all SPAM-filtering and content refusal directly at entry (i.e., on the Postfix side, using amavis in combination with milter), which then sends things on to the Exchange server(s) we maintain (and which don't do any further content filtering of their own). As the amavis integration into the Postfix delivery system is done using milter, there is no problem refusing a message at EOM (which is not [easily] possible in the case that you have a Dual-MTA setup [the amavis default for Postfix], which is similar to your case with Postfix relaying to Exchange). If you can't move the mail filtering infrastructure to the Postfix system (i.e., to the initial mail dialog when you accept responsibility for the message), the only sensible thing to do would be for the Exchange systems to not reject the messages, but mark them as SPAM and then do server/client-side filtering. From what you tell, the amount of SPAM that gets through is so miminal (25 messages a day for I guess quite a lot of users), that explicitly moving them to a spam folder for the user to decide what to do should be a perfectly acceptable policy, and a policy that is in compliance with your obligations. HTH! -- Heiko Wundram Gehrkens.IT GmbH FON 0511-59027953 | http://www.gehrkens.it FAX 0511-59027957 | http://www.xencon.net Gehrkens.IT GmbH Strasse der Nationen 5 30539 Hannover Registergericht: Amtsgericht Hannover, HRB 200551 Geschäftsführer: Harald Gehrkens, Daniel Netzer
