Re: New default settings for "submission" service?
On Mar 14, 2012, at 21:03, Patrick Ben Koetter wrote: > * Charles Marcus : >> On 2012-03-14 2:39 PM, Ed W wrote: >>> I see no reason to *require* encryption on the submission port (RFC >>> aside). >> >> Unless you prefer that sniffers not be able to see your passwords >> crossing the wire in plaintext? >> >>> I think "may" is a more appropriate default? >> >> Disagree vehemently. > > The RFC on submission is clear about that. It says SHOULD and not MUST. It is > safe to AUTH if you use cram-md5, digest-md5, ntlm or any other non-plaintext > mechanism. Forcing TLS by default is safer, but it pushes a policy on people > the SHOULD decide themselves, I think. From what I remember when we spent some time deciding our new defaults, all the methods that hash the password before sending it over the wire require that the server stores the plaintext, or at least the hashed versions of it. This was considered insecure, so we went with enforced TLS, and 'plain' auth only. Also, in our experience, pushing a policy that leaves no wiggle room tends to be a Good Thing for most users. To each their own, of course :-) Cya, Jona
Re: New default settings for "submission" service?
On Mar 14, 2012, at 19:39, Ed W wrote: > On 13/03/2012 23:50, Wietse Venema wrote: >> #submission inet n - n - - smtpd >> # -o syslog_name=postfix/submission >> # -o smtpd_tls_security_level=encrypt > > I forget the exact details now, but one mail client, I think it might be an > Android or iPhone mail client(?) defaults to using the submission service but > without encryption. The error messages were confusing and unhelpful to the > customer and I just recall it took some time to realise that it was the > enforced tls requirement that was the problem > > I see no reason to *require* encryption on the submission port (RFC aside). > I think "may" is a more appropriate default? I don't know about Android, but we have not seen any issues with the iPhone/iPad. Works fine with TLS 'encrypt' in our setups, as suggested above. Cya, Jona
Re: Stan's List [was: free antivirus scanner ?]
On 13 jan. 2012, at 21:13, email builder wrote:
>>> We use a modified version as a HELO blacklist. This avoids the false
>>> positives we saw while testing it as a reverse DNS restriction but,
>>> because the use of the reverse hostname as the HELO string is a
>>> common pattern in spam attempts from compromised hosts, it's still
>>> very effective.
>>
>> Interesting... can you provide specific details on what you mean by
>> 'modified version'?
>
> I second that. I'm feeling convinced enough to use it as it was
> intended, BUT ideally, I don't desire rejecting even those stubborn
> people who insist on running their email server from their bedroom
> without relaying through their ISP.
>
> Do you have a script that modifies the list into whatever format your
> method requires?
>
> Does anyone have any comments on the efficacy of this method?
>
> I assume all it would take is for bots to change the way they
> create their HELO hostname to bypass this.
The modifications are rather basic, really.
We've commented out some lines that were giving us false positives,
and modified the REJECT message to match its context, as well as
adding the error code we use for post processing and the like.
Legitimate mail servers aren't an issue for us, since they do not
use the reverse DNS string as their HELO greeting, and therefore
they do not get rejected. They might get rejected for other reasons
(hello 'sbs2003.local'!) but that's not during this step.
It's currently maintained by hand, as automating it would take
more time that it'd save right now. Premature optimization etc.
As for bots changing their habits, I am not worried. New patterns
do emerge at times, but old habits die hard. If at some point it
turns out that it is no longer as effective, like after an upgrade
to 2.8 or higher, it will be reevaluated.
Cya,
Jona
--
P.S.: As for false positives, we had to comment out the following;
/^dd[1-9][0-9]{3,5}\.kasserver\.com$/
/^h[1-9][0-9]{3,7}\.stratoserver\.net$/
They are the default HELO strings for DS/VPS providers here in
Europe. The reverse DNS has often been updated to match the
domain name of the main website or whatever, so it tends to be
unique to our way of using the list.
We have tried in the past to get people to update their HELO, but
that turned out to be futile, and the amount of FPs we get from
it are higher than the spam attempts blocked.
Hence their removal from the list. YMMV, of course :-)
Re: Stan's List [was: free antivirus scanner ?]
On 11 jan. 2012, at 16:12, email builder wrote: >> http://www.hardwarefreak.com/fqrdns.pcre <-- Stan's big list > > So who is using Stan's list? What do people have to say about > it? What should I consider in regard to possibly implementing it? We use a modified version as a HELO blacklist. This avoids the false positives we saw while testing it as a reverse DNS restriction but, because the use of the reverse hostname as the HELO string is a common pattern in spam attempts from compromised hosts, it's still very effective. It's a 'check_helo_access' restriction in our 'smtpd_recipient_restrictions', and sits right before our RBL checks, where it has blocked 17235 attempts so far this year, with zero false positives since we started using it, in November somewhere. So another 'Thanks!' to Stan for providing something that saves us quite a bit of time :-) Cya, Jona
Re: Address Rewrite Problem
On 9 apr 2011, at 18:54, Nasser Heidari wrote: > We have an Exchange for our local Emails and Exchange uses Postfix as > Smarthost. > Address Rewriting is Working properly for Emails from Exchange to > Outside network, but For Emails from Exchange to Postfix Virtually > hosted Domains or Postfix Local Mailbox's the rules doesn't Affect ! If Exchange is not sending using the correct address, I would suggest solving this within Exchange. Add additional SMTP addresses to accounts within your Active Directory, and pick the right one as the primary address, which will then be used by Exchange for all outgoing mail. No rewriting logic required. If that doesn't solve your issue, be more specific. See the previous responses by Noel and Victor. Cya, Jona
Re: submission port : "Client host rejected: Access denied"
On 6 mrt 2011, at 22:34, Noel Jones wrote: > On 3/6/2011 9:08 AM, DTNX/NGMX Postmaster wrote: >> >> I suspect that if you were to increase logging detail, you'd find that >> 'permit_sasl_authenticated' evaluates to zero during the client restrictions >> stage because of a delay in getting back an answer from whatever SASL >> backend you have in use. Postfix evaluates the rest of the client >> restrictions, and denies you access. > > No. The SASL authentication happens after CONNECT and HELO, before MAIL > FROM. With "smtpd_delay_reject = no", and "smtpd_client_restrictions = > permit_sasl_authenticated, reject" you're checking for sasl authentication > before the authentication ever has a chance to take place. > > This has nothing to do with what you're using for a sasl backend, because the > backend is never consulted. > > Just another good reason to not muck with the defaults. Hmm, I must be remembering it wrong then, because that makes perfect sense. Or I interpreted the logging data incorrectly, which is not impossible either. Anyway, thanks for the correction. Cya, Jona
Re: submission port : "Client host rejected: Access denied"
On 6 mrt 2011, at 15:08, David Touzeau wrote: >>> but it seems that postfix did not want to test the authentication >>> method and pass it's rules trough subnet rules to finally refuse the >>> connection with a "Client host rejected: Access denied" [snip] > smtpd_delay_reject = no http://www.postfix.org/postconf.5.html#smtpd_delay_reject Here, most likely. Ran into something very similar last week, and this was the cause. I suspect that if you were to increase logging detail, you'd find that 'permit_sasl_authenticated' evaluates to zero during the client restrictions stage because of a delay in getting back an answer from whatever SASL backend you have in use. Postfix evaluates the rest of the client restrictions, and denies you access. Try setting 'smtpd_delay_reject' to yes, which is the default, and consolidate all your restrictions under 'smtpd_recipient_restrictions' instead. Cya, Jona
Re: Please Test ... was: FrontBridge RFC 2920 write-up
On 11/12/2010, at 18:17, Michael J Wise wrote: > On Dec 9, 2010, at 2:12 PM, Wietse Venema wrote: > >> Michael, thanks for helping. > > Most welcome, glad I could help. > > Just out of curiosity, and because so many back at the ranch are asking... > Does anyone know if this problem just surfaced, or has been a latent issue > for a long time? > How long has this been going on? We added the pipelining workaround on November 8th, so early November would be a decent bet, did not see it before then. Removed the workaround when you announced the fix, not seen it since, so it seems to be fixed alright :-) Thanks for the effort! Cya, Jona
Re: postfix as incoming relay to protect exchange server / recipient lookup
On 05/12/2010, at 18:19, mouss wrote: > Le 03/12/2010 01:55, Stan Hoeppner a écrit : >> Victor Duchovni put forth on 12/2/2010 4:27 PM: >> >>> The OP is really far better off querying the LDAP server: >> >> That may be Viktor. I think he should test both and pick the solution >> that works best in his environment, both from a performance and >> management perspective. Choice is usually a good thing, and he has >> plenty with Postfix. :) > > let's look at this from the exchange server viewpoint: > > - with ldap, exchange sees no (RAV) connections. > - with RAV, exchange is hit for every address to verify > > Given all the job that exchange does (or is supposed to do), and the costs of > the licences if you need to add new servers, then you'd better hit the AD > server. > > if you really want caching, then setup an intermediary postfix that does ldap > lookup and hit it with RAV... This sounds a bit like premature optimization, which some say is the root of all evil. It also violates the 'Keep It Simple, Sysadmin' principle ;-) Exchange isn't the most efficient mail server, but I'd suggest that, for the majority of Exchange deployments, you probably need to look elsewhere if the simple SMTP transactions iniated by RAV are causing a performance problem. In our case, most of the unwanted connections never make it to the RAV stage, as it's one of the last checks done, and the majority of all remaining connections seems to hit the local cache. As far as I'm aware we see very few SMTP dictionary attacks, and they all tend to bounce off one of the earlier verification steps. A 'check_recipient_access' map with known exceptions for example, such as deactivated accounts, the usual suspects such as 'iamjustsendingthisleter' and so on. Of course, YMMV. I agree with Stan, test it and keep what works best for your setup. Cya, Jona
Re: postfix as incoming relay to protect exchange server / recipient lookup
On 02/12/2010, at 13:19, Martin Kellermann wrote: > Am 02.12.2010 13:11, schrieb Eero Volotinen: >>> but i see a strange "double-bounce" in mail.log which i don't understand: >> double-bounce is account used for validation of user account. > > thank you for explaining this... so everything seems to be fine so far... > is this user name configurable? Yes, it's the 'address_verify_sender' parameter, see; http://www.postfix.org/postconf.5.html#address_verify_sender http://www.postfix.org/postconf.5.html#double_bounce_sender Ours is set to 'senderverificat...@dtnx.net', since we use it for SAV as well, and that's where it's visible to others. We've seen similar setups from others as well, as well as the null sender address, 'postmaster' and so on. For use with your own backend (as RAV) it probably won't matter as much, but could still be useful for instant recognition while reading logs. HTH, Jona
Re: postfix as incoming relay to protect exchange server / recipient lookup
On 02/12/2010, at 23:08, Stan Hoeppner wrote: > Martin Kellermann put forth on 12/2/2010 6:08 AM: > >> and there's a 5 sec. delay ... seems way too long to me for just >> checking the recipient...!? > > That delay should be no longer than what a typical delivery to the > Exchange server would be. Since no message is sent, it should be > shorter by quite a bit. I would guess the delay is within the Exchange > server, not Postfix, so you may need to do some sleuthing on the Exch > server to see what it causing the delay. A testing tool like 'swaks' is great for testing RAV and other SMTP transactions; http://jetmore.org/john/code/swaks/ >> PS: should unverified_recipient_reject_code set to 450 or 550 ? > > You should probably leave this at the defaults. As I understand it, the > default configuration will return a 5xx for "unknown user" and a 4xx if > the query fails, due to network, etc. The default is '450' for both unknown users and transient errors, see; http://www.postfix.org/postconf.5.html#unverified_recipient_reject_code From the same page: "The unverified_recipient_reject_code parameter specifies the numerical response code when an address is known to bounce (default: 450, change into 550 when you are confident that it is safe to do so)". We also found it very handy to set up our 'notify_classes' parameter, so the postmaster (or any other user you configure) gets a transcript of the SMTP session when Postfix rejects mail. Note however that this adds load and can generate a large volume of messages to the postmaster. It works for us at our current volume, YMMV. Lastly, you may want to set a value for 'unverified_recipient_reject_reason' if you don't want to share the details of the backend server, such as hostname and/or IP address, with the outside world. Cya, Jona
Re: Upgrade version 2.5.5 to 2.7.1
On 01/12/2010, at 23:40, Stan Hoeppner wrote: > Victor Duchovni put forth on 12/1/2010 3:41 PM: >> It would be unwise of LaMont or Debian, having selected a particular >> Postfix 2.x release (say 2.7) to not track the patch updates from time to >> time. I understand that Debian stable or backports won't switch from 2.7 >> to 2.8 any time soon, but they should integrate patches in a reasonably >> timely manner (weeks to months, not years). Between 2.7.1 and 2.7.2 we >> have the changes below. They are not "critical", but O/S distributions >> still need to not sit on bug-fixes too long... > > I'm not exactly sure how, or if, this is handled. I don't recall seeing > any updates to 2.5.5-1.1, security or otherwise, since Lenny was > released in Feb 2009. Maybe I don't have the correct set of apt sources > configured? Unlikely but possible I guess. According to the Debian package database, there haven't been any; http://packages.debian.org/search?suite=all&searchon=names&keywords=postfix Here's the changelog for the 2.5.5 branch in Debian; http://packages.debian.org/changelogs/pool/main/p/postfix/postfix_2.5.5-1.1/changelog And the changelog for the 2.7.1 branch the backport is probably based on; http://packages.debian.org/changelogs/pool/main/p/postfix/postfix_2.7.1-1/changelog It seems they integrate upstream releases in packages while they are in the 'unstable' suite. Things then move into 'testing', which is currently the 'squeeze' release. They've frozen 'squeeze' in August this year, and are working towards release, which probably means they're not introducing any new code. As far as I can tell, 2.7.2 is from last week, correct? If you needed the fixes provided, you could grab the Debian source package, the Postfix source, change the package description file and compile .deb packages for deployment. That's what we would do anyway, once we upgrade our current 2.6.x to the 2.7 branch. Cya, Jona
Re: postfix as incoming relay to protect exchange server / recipient lookup
On 01/12/2010, at 23:18, Stan Hoeppner wrote: > Martin Kellermann put forth on 12/1/2010 9:19 AM: > >> so, is it still (seven years later) "The right thing™ to do" ? >> will it work proper with exchange 2007/2010 ? >> since the usage of "script-generated map-files" will never show >> a real-time picture of the valid exchange-recipients to postfix, >> isn't it nicer to do "online LDAP requests" from postfix? >> maybe this is possible with a LDAP-SASL plugin...? > > If you have very few users, say 1-100, and your organization doesn't > have frequent personnel changes, I recommend using relay_recipient_maps > and manually editing the table when needed. > > If more than that, for many reasons, I recommend using recipient address > verification instead of LDAP lookups, assuming you have decent spam > filtering techniques on your Postfix gateway, which is a requirement in > today's world anyway. > > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient > > The main reasons I recommend this over LDAP are: > > 1. These probes are typically faster than LDAP queries > 2. Recipient verification caches probe results reducing query load >and increasing performance. AFAIK LDAP results aren't cached. > 3. _VASTLY_ simpler configuration compared to LDAP > 4. Doesn't require LDAP support be compiled into your Postfix package > 5. You get a _realtime_ answer regarding SMTP mailbox availability. >An LDAP response may differ from an Exchange SMTP response due to >a number of reasons, such as AD synchronization, etc. This is >probably rare, but it can happen. I would suggest that in most cases, the RAV option is probably the best choice, unless performance is an issue because of hardware constraints, or mail volume? Compared to maintaining a recipient map it is pretty much automatic once set up, and very resilient when it comes to changes to your Exchange server and/or AD servers. Which you'll love when you are not the person maintaining the Exchange server, or someone in upper management decides that all accounts should have aliases for all the common typos they can think of. Compared to LDAP it can be easily tested using any telnet client, does not depend on having a valid account within the AD forest, and is configured using the transport map entry you need anyway to deliver mail. You don't need any additional firewall rules either, beyond the port you use for SMTP traffic. We use RAV on our MX servers to route mail to clients with Exchange. Simple, and it works like a charm. Cya, Jona
Re: OT, but mail related
On 24/11/2010, at 21:40, Stan Hoeppner wrote: >>> You'd be better off with SliceHost (RackSpace) than HE, and SliceHost >>> sucks from a delivery standpoint. >> >> Hmm... Interesting. Delivery as in transactional or bulk? I only had one or >> two slices from them, and off the bat had decent reputation for >> transactional messages. Every once in a while had a Yahoo transfail, but >> that was corrected very easily with a simple email to their postmaster. >> >> Just something that differs from my previous, yet limited, experience with >> them. > > Both can have problems with bulk. Slicehost shouldn't have many > problems with transactional email as RackSpace has worked pretty hard to > keep the snowshoe spammers off their network, whereas HE can, due its > reputation of hosting hordes of snowshoe spammers over the years, _and_ > hosting a ROKSO spammer, as I already mentioned. That alone is a _HUGE_ > red flag to many receivers, especially given he's been on their network > for 3 months without being booted. If you're going to Slicehost route, be sure to request exceptions for your IP address(es) on the Spamhaus PBL, as they got impatient last year with Rackspace cloud IP space, and put them on the SBL. The solution was to be moved to the PBL instead, but that means you'll be on there by default unless you explicitly request said exception. See this post from last year for some background; http://status.slicehost.com/2009/11/11/email-issues-spamhaus-pbl Monitor it as well, as they seem to expire PBL exceptions after a while. HTH, Jona
Re: Mail.Global.FrontBridge.com
On 27/11/2010, at 06:59, Michael J Wise wrote: >> Microsoft pay no heed to standards, ... > > Microsoft pays heed to standards, or a lot of the Internet just wouldn't work. This does seem a bit funny, given the subject under discussion. I understand that it is a big gorilla, and hard to turn on a dime, if at all. I also understand that it is a complex infrastructure consisting of a mix of frontend and backend servers, load balancers etcetera. But put your money where your mouth is, I'd say ;-) Working 'postmaster' accounts for the 'frontbridge.com' and 'bigfish.com' domains, read by clueful people would be a good start, instead of the bounce I got when we tried to report the PIPELINING issue on November 8th; : host 10.9.14.23[10.9.14.23] said: 550 : Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command) Reporting-MTA: dns; mail15-tx2-R.bigfish.com X-Postfix-Queue-ID: 295AE2E03D4 X-Postfix-Sender: rfc822; supp...@ur.nl Arrival-Date: Mon, 8 Nov 2010 21:18:23 + (UTC) Or the runaround we got when we tried alternate channels to report a problem, last year, with missing DNS records for some of the nodes in the cluster. The person it eventually got to wanted to know why we wanted to contact 'postmas...@bigfish.com', when he got the (fully documented) problem right there in the same e-mail. Another November 8th, actually, perhaps that's just a bad date over there ;-) We currently have a '*.bigfish.com' exception in place for our EHLO resolve check, and for the PIPELINING problem we've got this in our 'main.cf'; == # Added to deal with MS Frontbridge madness (2010/11/08 21:50) smtp_discard_ehlo_keywords = pipelining == I bet most of the people here are not interested in Microsoft bashing, they just want to keep the spice flowing. And given Microsoft's history, this being ANOTHER problem in a long line of issues the average mail admin has had to deal with with regard to Microsoft products and services, without being able to get a proper response from a human being ... perhaps you can understand where some of that frustration originates :-) Anyway, thanks for the response, and the effort you're putting in. Hope you'll be able to make a fix happen. Cya, Jona
