Re: deflecting attacks
Martijn de Munnik wrote, at 08/22/2009 02:06 PM: I use fail2ban with ipf on Solaris 10. When a host produces to many 5xx errors or sends to much spam it is banned in the firewall. failregex = reject: RCPT from (.*)\[HOST\]: 5\d\d ban time 1h failregex = Passed SPAM, \[HOST\] ban time 10m When a host is banned multiple short times it gets banned for 1 day. It should be easy to get this working with iptables. While fail2ban is an excellent tool (as is the recent module in iptables), don't go overboard. For example, keep in mind that SMTP is a very different animal than SSH or HTTP when determining sane amounts of time to block a host. It's relatively safe to block repeat offenders from SSH/HTTP because they usually represent connections from individual clients (although you might catch a proxy or network behind a NAT). But legitimate SMTP connections tend to come from a shared resource, such as an MTA representing thousands of clients. Don't set yourself up for a DoS by allowing someone to easily block Gmail, AOL, etc. at your site simply by sending a few spam messages.
Re: Wildcard certs - why only one level deep?
Chris Simmons wrote, at 08/07/2009 05:19 PM: In testing (and by reading the archives) I have found that postfix only supports one level of wildcard SSL certificates. That is to say, I can get a certificate for *.example.com that will match host1.example.com and host2.example.com, but won’t match mail.host1.example.com or mail.host2.example.com. Is there a particular reason behind this implementation, and is there any way to work around it? I understand that wildcard certs can be considered a security risk, but is the risk really much greater if it includes a longer hostname? *.com 'nuff said.
Re: Reverse DNS requirement
Robert Schetterer wrote, at 08/03/2009 03:40 PM: lost mail to where ? gone universe *g? the mail got rejected at last with a debug code so the sender may take his brain to fix its problem or try to reach you by phone , valid mailservers etc if the sender cant fix it you can simply whitelist them by ip or else for reject_unknown_reverse_client_hostname mail must always be supported using reject_unknown_reverse_client_hostname is relativly save these spam days ,shows every day work here, the few problems a year are easy to fix, make sure that you have very good dns resolves ( i.e use local dns cache too) i changed the reject code to 550, to let senders know at once about the the problem, for fighting bots it very effective ,and dont break your head about crying users behind if the senders cant show bounces and call it lost mail *g In this particular case, human senders are rarely the issue. As you suggest, they will often find ways to communicate to the recipient that there is a problem. Unfortunately, a substantial portion of the messages rejected by reject_unknown_(reverse_)client_hostname are sent by automated processes using misconfigured software or machines that bypass the more sensibly configured relays for a domain. Nobody will attempt to contact the recipient, who will often determine there is a problem when it is too late. Maintaining whitelists isn't an attractive option when there is already too much guesswork involved.
Re: sieve instead procmail?
Michael Monnerie wrote, at 07/23/2009 10:33 AM: I just need a sieve that can call an external program to deliver mails. Is that really not existing? Sieve is deliberately crippled in this way: http://sieve.info/ One of its design goals was to reduce the chance of users performing potentially insecure actions. It's not a drop-in replacement for programs like procmail.
Re: Mutt, postfix setup for multiple e-mail accounts
Vikas Rawal wrote, at 07/06/2009 07:41 PM: On my laptop, I use mutt with postfix for sending e-mails FWIW, recent development versions of mutt support SMTP: http://www.mutt.org/doc/devel/manual.html#smtp I haven't tried it yet, but I plan to. Although I used mutt often, lack of built-in SMTP client support was becoming a real showstopper.
Re: ISP being blocked by us
Ignacio Garcia wrote, at 06/26/2009 08:38 AM: FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.9 CLIENT_NOT_MX/A_FROM_DOMAIN=9.1 Both of these rules are absurd. An MX record is only relevant when determining the destination for a domain's email. It has *nothing* to do with relaying to other sites. You should remove these silly checks.
Re: rejecting client=unknown[ip.ad.dr.ess]
LuKreme wrote, at 06/23/2009 02:58 AM: On 22-Jun-2009, at 18:29, mouss wrote: Is there anyway to, if not outright reject anyone whose DNS shows up as unknown to at least tempfail them with a Ooops, your DNS is not resolving, try back later or something? if you insist, you could use one of http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname but use at your own risks. In particular, reject_unknown_client_hostname (previously: reject_unknown_client) _will_ block or delay legitimate mail. Will it block or delay it? Can I set the error code to a tempfail instead of a outright rejection. Blocking legitimate mail that fails dns checks is one thing, rejecting it outright is another thing altogether. When using the default response code (450) the practical effect is that the sending MTA will continually try to resend the message and you will continually deny it until it gives up. Thus, it is blocked, at higher expense for both sides. The only *true* delay will occur when the sender fixes DNS or you relax your restriction, allowing the message to be delivered. You are correct that changing unknown_client_reject_code to 550 is not something that should be considered lightly.
Re: Postifix-v-Spamassassin BLOCK SMTP
Steve wrote, at 06/23/2009 04:21 AM:
Silly question. Currently I have Postfix using Spamassassin as a content
filter thus;
smtp inet n - - - 10 smtpd
-o content_filter=spamassassin
...
spamassassin unix - n n - - pipe
user=spamd argv=/usr/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
It's nice and dandy but could this be changed to filter and reject at an
SMTP level rather than after accepting the message?
I use spampd (Spam Proxy Daemon) to do this:
http://www.worlddesign.com/index.cfm/rd/mta/spampd.htm
It doesn't look like it's being developed anymore, but I continue to use
it with latest versions of Postfix and SpamAssassin.
I believe you can also use amavisd-new as a before-queue content filter,
but the documentation strongly discouraged it the last time I looked.
I'm only running a small server with a few mails per minute - so it's
not going to kill it.
Then you're a good candidate. I doubt if it scales well to large volume
sites.
I can block at SMTP level with Postfix native Body Filter.
Actually, I use a header_checks rule:
/X-Spam-Level: \*{5,}/ REJECT
It works very well, and I can adjust the number in relation to the
default SpamAssassin required_score. I highly recommend leaving
required_score at the default of 5 and only adjusting individual rules
as needed. The collective wisdom of the SpamAssassin devs has served me
well, for the most part.
The reason I ask is this bounce;
...
ia...@varna.net: host mail.varna.net[217.145.80.1] said: 550 5.7.1
Blocked by
SpamAssassin (in reply to end of DATA command)
...
Whether you use a milter or a before-queue content filter to reject
during SMTP, be sure you have implemented as many low-cost measures
beforehand as possible. Processing by SpamAssassin always represents a
relatively significant resource hit, so try to limit it to the few
messages that survive the gauntlet of other, cheaper, techniques.
Re: Postifix-v-Spamassassin BLOCK SMTP
EASY steve.h...@digitalcertainty.co.uk wrote, at 06/23/2009 09:12 AM:
Joey wrote:
Actually, I use a header_checks rule:
/X-Spam-Level: \*{5,}/ REJECT
I wrote;
I looked at this myself and asked 'hang on, what if I put a header
filter in for X-Spam-Level'. I assumed (and that is all it was) that it
was not fed into the content filter until *after* Postfix had accepted
the whole message. ? ? If that is the case and it tried to bounce this
I'm not entirely sure of the carnage this would create. I'll have to
play with it as this looks like to easy and obvious to miss!
And yep, having tested it - that does not work as intended;
250 2.0.0 Ok: queued as C4E83AC0C6
So it takes it and then has to bounce it :-(
It then tries to 'bounce' and could end up joe-jobbing some innocent
person. I just did.
I assume you tested it with your current after-queue content filter. You
must use it with a before-queue content filter (AKA smtpd proxy):
http://www.postfix.org/SMTPD_PROXY_README.html
Set up spampd as a before-queue content filter, and header/body_checks
will reject during SMTP.
Re: Regular expression with fighting against spam
Jaroslaw Grzabel wrote, at 06/19/2009 10:44 AM: Not in the times when IPS's are obligated to run smart hosts for their customers and relay mails also for all hosting customers in the times when mobile operators gives you a possibility to connect from any place on the world using each time when you're connected different IP address. For relaying, SMTP AUTH on port 587 solves this problem entirely. How do you imagine to create 45k users with 10-15k domains ? It's faster to create access lists/maps and filter everything. Creating something like openrelay server but with stricts ACL. If your server is an MX for a domain, it MUST NOT accept mail for invalid recipients. Doing so creates backscatter and potentially creates problems for all other domains on the Internet. To defend I'm asking simply just only for a one rule which will exclude pipe from the address. To be fair, your original question reveals that you are somewhat unfamiliar with basic concepts of email administration, and that is why noone is eager to help you shoot yourself in the foot, especially if it means the bullet may ricochet off the floor and hit us. That said, you must escape the pipe: /^\|/ REJECT And you must also apply this rule to the envelope sender, not the From: header. See the Postfix docs for more information. But it's a moot point. You are fixing the wrong problem. Anyway you have no other choice in such a solution as smart host is. You are mistaken. Please do more research and fix your configuration according to best practices.
Re: SSL
Postfix wrote, at 06/16/2009 11:23 PM: Hi, I am trying to setup SSL connections. I have it setup as the instructions say: smtpd_tls_CAfile = /etc/postfix/sslbundle.crt smtpd_tls_cert_file = /etc/postfix/server.crt smtpd_tls_key_file = /etc/postfix/server.key smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache tls_random_source = dev:/dev/urandom smtpd_tls_security_level = may smtpd_use_tls = yes smtpd_tls_auth_only = yes smtpd_tls_loglevel = 3 If I telnet I get: 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN showing STARTTLS is in there. But when I setup my email client to use ssl for outgoing, I just get an error. You left out the important part: What is the error? If I add -o smtpd_tls_wrappermode=yes To the master.cf file for smtp, then it works, but the server will not receive any incoming mail since it is trying to use ssl. Undo that change. You shouldn't need to tweak the settings for smtp in master.cf. As you've discovered, this doesn't really work. The only way I can make it work is to setup the master.cf file with the smtps file for port 465 with the -o smtpd_tls_wrappermode=yes (as the default master.cf file has) and change my email client to use ssl with port 465 as the outgoing server. Okay, your client understands smtps and isn't complaining about the certificates. That's a potentially good sign. What client are you using? Have you tried another? Then I can receive email normally and use ssl to send out the email from the client. This is hopeful. It indicates that at least some of your settings are correct. Is this the normal way? I can't use port 25 for optional ssl connections? (as in users trying to send mail use ssl, but incoming mail from other servers don't have to use ssl) STARTTLS on port 25 is conventional, submission using STARTTLS on port 587 is preferable, and smtps (wrapper mode) on port 465 is deprecated and should only be enabled if you need to support legacy clients. We need to see the relevant lines from your server's maillog, the output of postconf -n, and more precise details about your client configuration and error messages. Try not to reveal your login credentials, which may be only trivially disguised. Also be aware that antivirus programs and firewalls can break encrypted connections to mail servers. You may need to disable them while you are troubleshooting and find workarounds if they are the source of the problem.
Re: backup mx and with header checks
Terry L. Inzauro wrote, at 06/15/2009 01:52 PM: I like the idea of verifying addresses, but this stuck out. snip from the Postfix Address Verification Howto WARNING The sender/recipient address verification feature described in this document is suitable only for low-traffic sites. It performs poorly under high load; excessive sender address verification activity may even cause your site to be blacklisted by some providers. See the Limitations section below for details. /snip what does the author consider as being low traffic? As long as you follow Noel's advice and don't accidentally the whole Internet, you'll be fine. :) Furthermore, you may want to configure the optional persistent verification database and tweak the settings as needed to reduce excessive probes to the domain: http://www.postfix.org/ADDRESS_VERIFICATION_README.html#caching http://www.postfix.org/verify.8.html Keep in mind that this approach (recipient address verification) is better suited for gateways and is a somewhat imperfect match for a backup MX. If the primary goes offline, there is still a risk that your backup server will reject legitimate addresses that are not present in the cache. Nonetheless, it is better than becoming a backscatter source (though a real dump of valid recipients is far preferable).
Re: Webmail
Carlos Williams wrote, at 05/19/2009 02:04 PM: On Tue, May 19, 2009 at 1:50 PM, Just E. Mail justem...@imwell-usa.com wrote: Thank you all. I am going with roundcube: http://www.roundcube.net It's really eacy to install. Main thing is making sure you have PHP 5.2+ installed on Apache and also configuring your MySQL database which is super easy if you follow the wiki. I did this on RHEL / CentOS and it worked great! If you need any more assistance, please let me know. There are a few things I wish I had known before it went live that I know now. I don't know your environment so if you need more info, please let me know! PS - They had a great forums but its down now for some reason. Their support forums is re-directed to some crazy Pokemon type page... I routinely block attack probes aimed at Roundcube. These have been active daily since January. I'm not concerned, because I don't use Roundcube and I am not intending to malign it here. But I recommend that you take a close look at its security history in light of these recent attacks, and see if there has been an adequate response. As with all applications, especially public facing ones, be sure to keep abreast of all security updates.
Re: question on permit_sasl_authenticated and check_sender_access
Charles Marcus wrote, at 05/06/2009 06:38 AM: On 5/6/2009, Gaël Lams (lamsg...@gmail.com) wrote: I modified master.cf and configure submission that way: submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Regards, What version of postfix was this? I believe newer versions (I'm on 2.5.6) should be something like: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_tls_auth_only=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject The OP might also benefit from changing the last line to: -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject This will override the corresponding smtpd_recipient_restrictions in main.cf and provide a simpler configuration appropriate to the submission service. Tweak as needed.
Re: question on permit_sasl_authenticated and check_sender_access
Charles Marcus wrote, at 05/06/2009 08:48 AM: On 5/6/2009 8:37 AM, Jorey Bump wrote: I modified master.cf and configure submission that way: submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject What version of postfix was this? I believe newer versions (I'm on 2.5.6) should be something like: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_tls_auth_only=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject The OP might also benefit from changing the last line to: -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject This will override the corresponding smtpd_recipient_restrictions in main.cf and provide a simpler configuration appropriate to the submission service. Tweak as needed. Hmmm... I'm wondering what the effective difference is (maybe I should change mine too?)... In this particular case, either will probably just work. The main advantage is that it matches the approach used in main.cf (handling all restrictions in smtpd_recipient_restrictions), so the override makes it possible to avoid restrictions specifically targeting the server's role as an MX. Another minor advantage is that the configuration will continue to work if permit_sasl_authenticated is removed from smtpd_recipient_restrictions in main.cf (if the decision is ever made to disallow submission on port 25, restricting authenticated users to submission port 587). It's slightly more portable, but only when assuming the common practice of handling all restrictions in smtpd_recipient_restrictions.
Re: question on permit_sasl_authenticated and check_sender_access
Charles Marcus wrote, at 05/06/2009 09:38 AM: On 5/6/2009 9:03 AM, Jorey Bump wrote: Another minor advantage is that the configuration will continue to work if permit_sasl_authenticated is removed from smtpd_recipient_restrictions in main.cf (if the decision is ever made to disallow submission on port 25, restricting authenticated users to submission port 587). I thought that it would still work this way when it is set to client_restrictions? Why would removing this restriction from recipient_restrictions in main.cf cause this setting in master.cf to no longer reject unauthenticated sasl sessions on the submission port? It will still reject (most) unauthenticated submissions, since they can't get past your smtpd_client_restrictions. That's not the issue. If the smtpd_recipient_restrictions in main.cf are not overridden in master.cf for the submission service, then they still apply. So, even if your submission service's smtpd_client_restrictions contains permit_sasl_authenticated, the authenticated user's messages to external domains will likely be rejected during RCPT TO if permit_sasl_authenticated is removed from smtpd_recipient_restrictions in main.cf (thanks to Sahil for pointing this out in an earlier thread). In other words, getting past smtpd_client_restrictions doesn't guarantee getting past smtpd_recipient_restrictions. You can test this by temporarily removing permit_sasl_authenticated from smtpd_recipient_restrictions in main.cf and attempting to relay a message to an external domain as an authenticated user via the submission port. With your current settings, the message should be rejected (unless permitted by something else, like mynetworks). If you're never going to disallow submission on port 25, don't worry about it. As always, YMMV depending on your configuration. It's slightly more portable, but only when assuming the common practice of handling all restrictions in smtpd_recipient_restrictions. Understood with respect to main.cf, but we're talking about master.cf. I really thought that it was better to be more specific in master.cf in this case. Hmm, guess I have more reading to do... Yes, it is. That's why you have to consider the global settings in main.cf and override them appropriately in master.cf.
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/30/2009 10:31 PM: On Apr 24, 2009, at 9:43 PM, Jorey Bump wrote: Since one of the purposes of the submission port is to support road warriors, I feel it should be as secure as possible and the entire communication should be encrypted. I am in a bad spot in this regard, because of some of the faults of my current email server. It is pushed a bit to move users to 587, but the server does not support SSL/TLS. It would be very hard for me to get them to all change their settings to use SSL/TLS. I would love to make 587 the default secure port, I just do not thing I can put my users in that situation. If postfix can log in a way that I can tell what is going on, and over time, I can make a call a day, and convert people over to TLS, eventually I will flip this switch. You can alter the name syslog uses for the submission service by adding: -o syslog_name=postfix-submission I recommend setting up port 587 correctly and securely from the start and migrating users gradually. Since they are already changing configuration settings, have them switch to TLS at the same time, so it doesn't have to be dealt with later. The new log name will aid in troubleshooting. You'll be able to tell who is still authenticating on port 25 because it will be logged under a different name. Just grep for sasl_username in your logs. In some cases, I allow the use of a secure mechanism without TLS on port 25. This protects the login, but not the message contents. I don't allow unencrypted plaintext logins. I am leaning back on this idea again. Have to hash that out from the standpoint of a proxy. I am just do not know if I gain anything by putting all user MUA traffic on a non port 25 port. I know the proxy tries to learn from users sending emails, and white list the recipients, I do not know if that learning is port bound or not. Well, that's another potential advantage of using port 587: you can spare authenticated users (and your system) from filter/proxy scans. Note that some environments still want to scan outgoing mail. Once again, the fact that you're using an alternate port allows you to customize settings to suit the purpose, so it can be another win. It's up to you. I use SMTP AUTH for webmail, partly because it provides better logging for troubleshooting. Good point. What webmail are you using? Does it globally SMTP AUTH via a config file and a smtp account, or is each user login it's own SMTP AUTH case, which is where you are picking up the logging data specific to the sender under that specific account? I use SquirrelMail, which uses individual login credentials for both IMAP access and SMTP AUTH. It's nice to have the user information in the logs. In fact, if you are using Roundcube, make sure it's fully patched. There is a vulnerability that is still being probed for daily against likely locations for it on web servers. Default autoconfiguration appears to use ports 25, 465, 587 and SSL if detected. The server I tested supports all of these and the mechanism list is PLAIN LOGIN CRAM-MD5 DIGEST-MD5. After autoconfiguration, Apple Mail used STARTTLS and the PLAIN mechanism on port 25 to send a message. Are there are good reasons to support PLAIN and LOGIN and PASSWORD? I have told all our users to use MD5 Challenge Response. Maybe I would aid Apple Mail in figuring out which to pick, it seems to always fall back on PASSWORD iirc. Perhaps other desktop clients do not support md5 mechanisms. PLAIN LOGIN are almost universally supported, and are safe to use over an encrypted channel. If you force encryption for plaintext logins, you get peace of mind and your users get more flexibility when configuring clients (which I've found to be a big win as they point and click randomly). I've also had to support some enterprise applications that have severely limited SMTP capabilities, so this extra flexibility comes in handy. A friend of mine signed up for some cheapo hosting account, and they had a apple script to set it up. It did not work, but I have been meaning to swipe it and fix it. It looks very simple to deal with, and you can shove the users login name in, so all they do is run it, connect to get email, enter in their password, and click remember and they are done. I would bet I can alter the default port in this script as well. That's one option, but you might be better off going with the autoconfiguration and providing instructions where that fails. Asking users to run scripts is sending the wrong message, IMHO. It just makes them more vulnerable to phishing and other exploits that rely on bad practice. You'll have to refer to your SASL implementation to see what mechanisms you can support. There can be some additional overhead with the secure mechanisms, but it's nice to have the flexibility. Also, some MUAs behaved unpredictably when certain mechanisms were absent as autoconfiguration was being developed
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/30/2009 10:11 PM: What happens is, under heavy MTA load on port 25, I will run out of connection slots on port 25. Have you investigated the nature of this problem? By moving users to 587, I do not care about port 25 connection slots. MTA's will try again later if busy. You might be chasing a red herring. If your server is overloaded, there is a reason why, and there may be more effective remediation techniques available. Improving your submission service is good, but it might not deliver the performance payoff you're expecting. What do you guys think? My end goal here is to get this all working, and then change these ports to, for example, 25 - 2525 and 587 - 587587 unless there is some other convention. I am going to put a anti spam proxy in front of all this. If you still have a heavy load, consider separating your MX entirely from submission, using separate instances/machines. It's generally easier to move the MX, since MUA configurations don't care about it. I just do not want to add too much to my learning curve, so first, get postfix to where I understand it, then toggle the ports and put the proxy in. It should blindly pass the traffic, I assume in much the same way stunnel does. I am open to any and all advice on this matter to make this work best. I have a feeling later on down the road I will need to learn exactly what things to disable in postfix, as it should not do any bouncing at all, anything that will lead to backsplatter, since I am putting a proxy ahead of it. FWIW, a poorly implemented proxy can do more harm than good. A lot of sites just toss them in, and don't pay attention to finer details like DNS settings and recipient validation. I am still not entirely clear. The docs: I am still not entirely clear. The docs: Do not configure client certificates unless you must present client TLS certificates to one or more servers. Client certificates are not usually needed, and can cause problems in configurations that work well without them. The recommended setting is to let the defaults stand That supports your statement. What is confusing, is most of the tutorials for setting up Postfix have a section on setting these up. Trust the Postfix documentation, not random tutorials. Indeed, the ones I set up used a specific host name, and when I smtp, or pop or imap, I am asked to authorize the self signed cert, as at this time I do not have a purchased cert from a CA. That's something else. You get that prompt from the server certificate (smtpd_tls_cert_file), which you need. That is different from the client certificate (smtp_tls_cert_file), which you obviously don't need. What is the correct way to not use certs for MTA's, but to present one to the MUA? # server TLS parameters smtpd_tls_key_file = /etc/ssl/yoshino.meidokon.net_key smtpd_tls_cert_file = /etc/ssl/yoshino.meidokon.net_crt smtpd_tls_auth_only = yes -- as mentioned, user can only auth on a secure connection smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes You have the two cert, ahhh, smtp*d*. Ok, I think I get it, that is for MUA traffic, and you present them a cert authorization when they are auth'ing. So I can even use the current certs I have in place now? These are for all client connections that use STARTTLS, not just MUAs. The difference is that MTAs typically don't quit if they can't verify the cert (check it against a root certificate store), so using a self-signed cert is adequate. It is increasingly harder to support MUAs with noncommercial certs, however. You can get basic ones fairly cheaply, so I recommend it to avoid annoying warnings to your users. # client TLS parameters, forward mail via TLS if possible smtp_tls_security_level = may I had this one already I believe. This is what you need for your server to connect *as a client* to other MTAs, opportunistically using STARTTLS when offered. The wrapper mode is probably a Outlook issue, or at least an older buggy MUA client issue? I do not have any easy access to Outlook. How do you go about testing before deployment? Don't set it up until you have everything else working properly (TLS, submission, etc.). Then wait until you find a need for it. Normally, the Postfix defaults in master.cf will suffice (assuming your distribution hasn't fiddled with them). smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem smtp_tls_key_file= /opt/local/etc/ssl/private/dovecot.pem Remove. smtp_tls_security_level = may Keep. smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache Keep if you need it. smtpd_sasl_security_options = noanonymous Change to noanonymous, noplaintext if you don't want passwords sent in the clear. smtpd_tls_ask_ccert = yes Why? smtpd_tls_cert_file = /opt/local/etc/ssl/certs/postfix.pem
Re: Suggestions on submission port config
Victor Duchovni wrote, at 05/01/2009 10:26 AM: On Fri, May 01, 2009 at 10:19:40AM -0400, Jorey Bump wrote: FTR: No, I didn't! :) My end goal here is to get this all working, and then change these ports to, for example, 25 - 2525 and 587 - 587587 unless there is some other convention. I am going to put a anti spam proxy in front of all this. There is no port 587587, the TCP port range (over both IPv4 and IPv6) is from 0 to 65535, but 0 means unspecified at the socket API level. In any case 587587 is usually equivalent to its residue mod 2^16 which is 63299, not a good port to choose for a service (dynamic port range on most systems).
Re: Suggestions on submission port config
Scott Haneda wrote, at 05/01/2009 08:37 PM: On May 1, 2009, at 7:19 AM, Jorey Bump wrote: The difference is that MTAs typically don't quit if they can't verify the cert (check it against a root certificate store), so using a self-signed cert is adequate. # client TLS parameters, forward mail via TLS if possible smtp_tls_security_level = may I had this one already I believe. This is what you need for your server to connect *as a client* to other MTAs, opportunistically using STARTTLS when offered. In a previous sentence you used the word 'typically' in regards to if the MTA will quit or not on seeing a cert. What is the risk here? Most connecting MTAs will still encrypt the communication if they cannot *verify* the certificate, so there is little risk of sniffing on the wire. Some policies will require verification, but that usually implies a special relationship. If I understand, this gives an opportunistic ability for MTA to MTA discussion to be secure, falling back on the old plain method if it is not available. Correct. Is there really a lot of exploiting going on in-between one MTA and another? From what I can tell, this would boil down to a rogue person at some router between me and say, gmails servers, that wanted to intercept traffic. Just does not seem likely. Which is why most MX hosts and relays use encryption opportunistically instead of enforcing it. Perhaps the days are numbered even for this innocent approach... smtpd_sasl_security_options = noanonymous Change to noanonymous, noplaintext if you don't want passwords sent in the clear. If I set this to noanonymous, noplaintext to confirm, if any of my current users are using an authenticated plain text login method, they would fail to login? In many cases, yes, because plaintext mechanisms won't even be offered unless the channel is encrypted. However, some clients might automatically use the remaining secure mechanisms that are still offered. This then gets my phone ringing, where I can help them make the changes to either use a non plain text login method, with auth, or use a plain style login with crypto. I think I have that correct. Yes. submission inet n - n - - smtpd -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated IMHO, too weak for port 587. Can we explore your HO on this. I have helped many a friend set up email for any number of the 9.99 a month ISP's out there, the are all offering normal 25, some alt submission port, and some SSL port as well. I am yet to see any particular mandate that the submission port be crypto mandated. Not that I want to just follow the examples set by others, as often is the case, they are doing it wrong anyway. I am just not seeing why a user can not auth with no crypto. Or, are you taking the stance that users really do not know about this stuff, and it would be best if you protect their actions on their behalf? No, I'm more interested in protecting the integrity of the submission service on port 587, and prefer to see it locked down as tightly as possible. The main reason is to prevent a breakdown in security that could lead ISPs to block port 587 as many have done with port 25. I've seen misguided configurations that duplicate port 25 settings on port 587, making the port a fully functioning MX that can be abused by spammers. Another reason is that some hotels and internet cafes arrogantly try to proxy email connections, and that's a lot more threatening than unencrypted MTA to MTA communication. TLS helps mitigate this, as it is really hard to proxy encrypted connections without generating a warning (unless they trick you into installing a root certificate in your client). I certainly can appreciate that. Having to deal with hundreds of iPhone users, and desktop users, when I toggle this switch may prove less than fun. Since my old server does not support SSL/TLS, it is not like I can send an email out, tell them to switch, and then mass move everyone to postfix. This is going to be a throw the switch, and start answering phone calls. I do really like the idea of all users being secure. Perhaps I will set up a new MX, run the old and the new at the same time, and migrate one domain at a time, that would remove the throw the switch support burden. Not really liking the idea of using a new domain for setting up the postifx server. I am pretty sure I can not do this in the same domain, as the second I add in a MX pointing to the new postfix server, that is going to break everything. You have your work cut out for you. What specifically about smtps was it that you ended up determining you needed it? I needed to support legacy clients. I don't enable it on new servers, though, unless there's a demonstrated need.
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/24/2009 07:58 AM: I am a little confused about main.cf and master.cf. Is there overlap in some of the settings? Do some settings exist in both files, or at least are interchangable? If this is the case, under what conditions do you decide to do so? From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer to other parameters as $name etc., just like in main.cf. See postconf(5) for syntax. As implied, it's useful when you need to override the settings in main.cf to get different behaviour appropriate to the service you're setting up in master.cf (submission, reinjection from proxy/filter, etc.). I successfully sent emails through this system as unauthenticated, authenticated, with tls, and with ssl. This is a migration, and I would like to have minimal email client settings needing change. My old server did not have SSL or TLS. Old Server: No SSL, No TLS port 25 = normal inbound, plus smtp auth'd users port 587 = forced auth'd users I am willing to disallow user connection to port 25. How do I do this? In main.cf or master.cf? Right now, I believe I only have this: [snip... master.cf ] smtp inet n - n - - smtpd I believe I need to add a restriction in there to stop clients from connecting? There was a recent thread on this subject, worth reading: http://www.mail-archive.com/postfix-users@postfix.org/msg06230.html For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. I can not seem to get this to work, it is either no encryption, or forced encryption. [snip... master.cf ] submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated -o milter_macro_daemon_name=ORIGINATING Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous * Do I even need the milter line? Good question. It may depend on whether or not you use milters. I don't, but I leave it in because I don't want issues later if I decide to deploy a milter. Port 465, I believe will be reserved exclusively for SSL? Port 587 does the TLS, is that correct? Or is the SSL just wrapping around the TLS? [snip... master.cf ] 465 inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING This is for legacy support. I suggest you don't activate it until you're sure you need it. Wrapper mode is different from offering STARTTLS. Nearly all modern clients support STARTTLS. If someone absolutely needs port 465, that could be a red flag that the user needs an upgrade. However, some webmail programs might have poor support for STARTTLS, forcing you to enable smtps if you require an encrypted connection. In Apple Mail, there are auth options of ntlm, md5 Challenge-Reponse, Kerberos, and Password. In Thunderbird I notices there are no such options. Which are used in Thunderbird? What is the best to use, or is it only applicable if you are choosing to not use SSL/TLS? Thunderbird has a Use secure authentication checkbox that supports multiple mechanisms (independent of SSL/TLS). Unfortunately, *it* decides which one to use, which I find very frustrating. I'm happy for mail clients to select the best mechanisms available for easy autoconfiguration, but it would be nice to have the ability to set them explicitly (for troubleshooting or security reasons). In any case, it's good practice to check this box if the server supports secure mechanisms, for a little extra protection beyond SSL/TLS. I have been pretty up and down the docs, this is somehow not making a lot of sense. I think once I understand what crosses over in config from main.cf and master.cf, it will make more sense. postconf -n smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem If you're not using client certificate authentication (and you probably aren't), delete those lines. smtp_tls_security_level = may This is good. smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticatedreject_unauth_destinationpermit You can remove permit_sasl_authenticated from here if you don't want to offer authenticated submission on port 25... smtpd_sasl_auth_enable = yes ...and change this to no (or remove the line,
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/24/2009 07:41 PM: Thanks for this, this is getting me on track, comments interspersed below... On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote: Scott Haneda wrote, at 04/24/2009 07:58 AM: I am a little confused about main.cf and master.cf. Is there overlap in some of the settings? Do some settings exist in both files, or at least are interchangable? If this is the case, under what conditions do you decide to do so? From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer to other parameters as $name etc., just like in main.cf. See postconf(5) for syntax. As implied, it's useful when you need to override the settings in main.cf to get different behaviour appropriate to the service you're setting up in master.cf (submission, reinjection from proxy/filter, etc.). I have a little affliction against man type pages, they never seem to make a lot of sense to me :) This section does though. Just to be clear, this is a full blown over-ride, in that deleting the corresponding value from main.cf would do nothing to the server, so long as it exists in master.cf? Yes. But keep in mind that most settings have a default value. It's healthy to define a base configuration in main.cf, where your needs differ from the defaults, then only apply overrides in master.cf where necessary. For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous If you do not like a lack of TLS enforcement on the submission port what do you suggest for users who just do not care enough to use any TLS? I suggest they use it if they want to send mail. :) Since one of the purposes of the submission port is to support road warriors, I feel it should be as secure as possible and the entire communication should be encrypted. You let them work on port 25? In some cases, I allow the use of a secure mechanism without TLS on port 25. This protects the login, but not the message contents. I don't allow unencrypted plaintext logins. I could go that route, but I am really trying to find a way to do traffic isolation. If I know no client connections are made on 25, from a troubleshooting perspective alone, it seems to make things simpler on me. I think it's reasonable. Just give your users advance notice so they can change their settings. Glad you brought up webmail. I am going to use Roundcube, on the same machine, worst case, on a close machine, in the same subnet. Since I have the nynetworks setting set to allow mail, all should be ok? I do not want to deal with AUTH for SMTP in webmail, it is going to be local to local, I see no point in securing that part. Is that correct? It's up to you. I use SMTP AUTH for webmail, partly because it provides better logging for troubleshooting. I am confused about your comments about 465. Reading it makes me think that 465 is sort of a last resort option. I am not understanding the difference between SSL and TLS. If I was setting up a email client, and could use TLS versus SSL, my logic would be to use SSL, it seems the better option, but I do not know why. Are you saying SSL email is the lesser of the options, and I should use TLS when I can? I'm saying that smtps (wrapper mode on port 465) is deprecated in favor of STARTTLS on ports 25 or 587. So the ideal situation is using TLS on a non 25 submission port? Ideally, STARTTLS on the standardized submission port 587. Do you know how this related to Apple Mail? There is no setting in the SMTP section to opt for SSL versus TLS? Use SSL is the only checkbox there is. I take it if you do not select that, it will use TLS if it can, but do so in a invisible way? Default autoconfiguration appears to use ports 25, 465, 587 and SSL if detected. The server I tested supports all of these and the mechanism list is PLAIN LOGIN CRAM-MD5 DIGEST-MD5. After autoconfiguration, Apple Mail used STARTTLS and the PLAIN mechanism on port 25 to send a message. I assume it follows an algorithm to determine a fallback strategy for trying the other ports if its first choice is not available. Although I would have preferred it start with port 587, the choice it made is acceptably secure. If you only offer port 587, it probably won't pose any problems (as long as it remembers the other ports are unavailable). In any case, you can set the port mechanism explicitly, and it will negotiate TLS/SSL appropriately for either wrapper mode or STARTTLS
Re: Postfix telnet authentication
Antonis Rizopoulos wrote, at 04/13/2009 09:55 AM: When I connect to my server, from different networks, to port 25 I am able to send emails to local users only without authenticate! It's like bypassing Cyrus-SASL. No, in this particular case it is not about you being allowed to *send* mail, it is about your users *receiving* mail addressed to them. There is a big difference. I know, of course, that I cannot block access to that port and allow only authenticated users to send emails, because I won't receive mails from web sites. But I think this is a huge security issue for my mail server. How so? The rest of the Internet can send messages to your users without authenticating. Why should your users be more restricted in this case? SMTP AUTH is about granting your users the privilege to use your server to relay mail to *external* domains.
Re: alias with no primary domain
M.A. GEERTSMA wrote, at 04/11/2009 09:08 AM: I configured my server with no/fake (primary) domain. So I only serve 4 virtual domains. But then the /etc/alias file is of no use for these domains. Is it true that I have to use the /etc/postfix/virtual for definining all possible email adresses? Or is there a way I can use a alias file for virtual domains too? You'll have to define all of a domain's possible addresses in virtual_alias_maps, but some configurations will still allow you to direct these addresses to an alias defined in alias_maps (I do this for all of my administrative addresses). Is there a specific problem you are trying to solve?
Re: Dumb question - How can I be sure that SMTP authentication is really working.
KLaM Postmaster wrote, at 04/11/2009 03:23 PM: KLaM Postmaster wrote: How can I be sure that SMTP authentication is really working. I have been trying to determine is there is a reliable way of checking is my SMTP authentication is working, I think it is working, but as I an only test from within my own network I am not 100% certain, Is the a tool or site that would allow me to verify this. Follow-up when I look in the my Mailllog I see this sort of thing: Apr 11 15:17:51 localhost postfix/smtpd[26037]: Anonymous TLS connection established from unknown[192.168.10.25]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) which makes me think that it is working, however is it normal for the connection to be anonymous? That log entry is about TLS and has nothing to do with SMTP AUTH. It's easy enough to confirm that SMTP AUTH is working by using a standard mail client to send a message to an external domain. You might want to configure and test the submission service on port 587 as you do this, because it is customary to restrict this service to authenticated users and exclude $mynetworks (so being on the same network is not likely to pose a problem). In most cases, you can uncomment the submission service in master.cf and use the defaults. Run your tests, then check your log for lines containing sasl_username or sasl_method. There are also tools available to check your configuration, depending on what type of authentication you're using.
Re: Sender with invalid domain
post...@corwyn.net wrote, at 04/10/2009 12:08 PM: Currently I block email with smtpd_sender_restrictions = reject_unknown_sender_domain check_sender_access hash:/etc/postfix/access smtpd_data_restrictions = reject_multi_recipient_bounce smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_non_fqdn_sender reject_unknown_sender_domain permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/agencies reject_unauth_destination check_client_access hash:/etc/postfix/access check_helo_access pcre:/etc/postfix/helo_checks reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net reject_rbl_client dnsbl.sorbs.net reject_rbl_client cbl.abuseat.org I've got a customer who has their Mailer-Daemon address configured to respond with an invalid domain so they get rejected: Apr 9 16:53:44 agencymail postfix/smtpd[1703]: NOQUEUE: reject: RCPT from theirotherbutvalid.example.com [x.x.x.x]: 450 4.1.8 mailer-dae...@their.example.com: Sender address rejected: Domain not found; from=mailer-dae...@their.example.com to=u...@my.example.com proto=ESMTP helo=theirotherbutvalid.example.com I'd like to be able to whitelist their.example.com so it won't reject (trying to convince them to fix it, but you know how it goes). With the above config, I think I would need to update /etc/postfix/access, but also change the order to: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access reject_unknown_sender_domain would I also need to do something withreject_non_fqdn_sender ? Yes, that would also need to follow the map. I recommend that you dedicate separate maps to check_sender_access and check_client_access; combining everything into one map is risky. I use the default of smtpd_delay_reject = yes and organize everything under smtpd_recipient_restrictions, so the pertinent part looks like this: smtpd_recipient_restrictions = ... check_sender_access hash:/etc/postfix/sender reject_non_fqdn_sender reject_unknown_sender_domain permit_mynetworks permit_sasl_authenticated reject_unauth_destination ... reject_rbl_client ... The addresses I want to whitelist are in /etc/postfix/sender: mailer-dae...@their.example.compermit_auth_destination Note that I'm only allowing delivery to my domains; they don't get relay privileges. If you want/need to continue using smtpd_sender_restrictions, you might need a more elaborate configuration. Otherwise, put it under smtpd_recipient_restrictions and be done with it.
Re: reverse lookups
ghe wrote, at 04/10/2009 02:54 PM: Oh, dear! I'm not sure what, if anything, I can do about this, but thanks to you all for the response(s). Maybe a non-caching name server might help. You've only indicated that an authenticated client's IP address does not reliably provide a reverse lookup. Why is that a problem? Is the connection being rejected? Authenticated users should be exempted from such checks. Provide the output of postconf -n. I'm thinking it's getting to be time to turn reject_unknown_sender_domain into a full reject instead of just a warning, but if DNS isn't working quite right. What is wrong with the sender's domain (MAIL FROM:)? You don't mention it in any of your posts. The unknown client issue you reported only involves resolving the connecting IP and is unrelated to reject_unknown_sender_domain (which is normally safe to reject, with varying philosophies on *when* is the best time to reject it). Of course, if you mention this only because you think your DNS is unreliable, it is a concern. But the type of problem you're reporting is often isolated to a few domains. If you're logging warnings for reject_unknown_sender_domain, you should be able to review the logs to see if there is a regular problem with your DNS (but this would also be apparent for outgoing messages, in a much more serious way).
Re: Spam list (dns hostnames)
M.A. GEERTSMA wrote, at 04/10/2009 03:13 PM: I will replace the 3 lines by the 1, but would that be double because of MailScanner. btw, MailScanner uses a local file: phishing.bad.sites.conf which is updated regulary. You're missing the point, and comparing two unrelated features. reject_rbl_client incurs the cost of a DNS lookup, but it's relatively inexpensive. zen.spamhaus.org is reliable enough for outright rejections, which can spare you the overhead of further processing downstream. If the message continues to the filter, and that filter decides to do another lookup, caching should make it even less expensive, but you can probably exclude a particular RBL if you really feel the tuning is necessary. None of the information you've provided indicates a duplication of effort, so I wouldn't worry about it until it becomes a problem. To improve performance, you want to use as many lightweight techniques as possible to *avoid* invoking MailScanner/SpamAssassin in the first place, saving it for the few that trickle through your initial gauntlet.
Re: DNS verification
berny wrote, at 04/08/2009 05:41 AM: 2. If yes, what type do you use? a) only PTR check [reject_unknown_reverse_client_hostname] b) or PTR=A check [reject_unknown_client_hostname] 3. What are your experiencies and opinion to it? I have found it unsafe to use either. At the very least, it will reject mail from poorly run (but legitimate) mailing lists. There are also an alarming number of schools, government and other nonprofit sites that cannot make it past these checks due to poorly configured DNS and the lack of expertise to correct it. At the extreme end, some major registrars cannot pass these checks, which could put domains at risk for recipients who depend on email reminders to renew their domain registrations. It's a shame, because enforcing these checks would have a noticeable impact on spam, especially FCrDNS: http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS Sadly, I have been unable to uncover a method to use FCrDNS in a scoring system. Ideally, I would like to use SpamAssassin, but if anyone knows of another way, please share. In any case, you can review the potential impact of the above directives by including this in smtpd_(client|recipient)_restrictions: warn_if_reject reject_unknown_reverse_client_hostname warn_if_reject reject_unknown_client_hostname Watch your logs and monitor potential rejections. Be aware, however, that it can take months to reveal something truly serious (like a yearly notification from a registrar).
Re: DNS verification
Henrik K wrote, at 04/08/2009 09:54 AM: On Wed, Apr 08, 2009 at 09:09:58AM -0400, Jorey Bump wrote: It's a shame, because enforcing these checks would have a noticeable impact on spam, especially FCrDNS: http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS Sadly, I have been unable to uncover a method to use FCrDNS in a scoring system. Ideally, I would like to use SpamAssassin, but if anyone knows of another way, please share. Don't bother looking too hard. :) Postfix records FCrDNS in Received-headers (unknown if not matching) and SpamAssassin uses that information in RDNS_NONE rule. Funny, I took that rule at face value and assumed it only indicated a missing PTR. Even funnier, I've been incrementally raising the score for months (currently at 4 points) looking for the sweet spot, so it seems I've been checking FCrDNS all along. Thanks for the info! Time to notch it up another point...
Re: DNS verification
Jorey Bump wrote, at 04/08/2009 09:09 AM: At the extreme end, some major registrars cannot pass these checks, which could put domains at risk for recipients who depend on email reminders to renew their domain registrations. I guess we can add PayPal to the list of major players with poorly configured DNS: $ host 206.165.243.120 120.243.165.206.in-addr.arpa domain name pointer email-120.paypal.com. $ host email-120.paypal.com Host email-120.paypal.com not found: 3(NXDOMAIN) It's surprising that PayPal, the target of so many phishing exploits, doesn't have squeaky clean DNS configured for its mail servers.
Re: my mailserver has been blacklisted
Ivan Ricotti wrote, at 03/26/2009 06:59 AM: I suspect that some windows users in my network is sending spam... and the question is: how can I prevent this acting on postfix? Don't speculate. Read your logs.
Re: saslauthd with realm support
Victor Duchovni wrote, at 03/16/2009 10:10 AM: On Mon, Mar 16, 2009 at 02:29:17PM +0530, ram wrote: For smtp-auth configuration, some users put full emailid as username , some use just the userid part of email-id(before '@'). Can postfix always authenticate with userid. Can this be done only for email-ids of some domain Postfix passes the data received from the SASL client verbatim to the SASL library. The rest is up to the SASL library. For clarification, what happens when smtpd_sasl_local_domain is set? Does the presence or absence of a realm in the login alter Postfix behaviour?
Re: non-alpha HELO
LuKreme wrote, at 03/14/2009 12:19 PM: On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... Actually, the specially designated syslog_name can be very useful, especially for troubleshooting migration. To see who's using the new port, use something like this: grep sasl /var/log/maillog | grep submit To see who's not: grep sasl /var/log/maillog | grep -v submit
Re: Export User
Sasa wrote, at 03/13/2009 09:08 AM: How can I Export my postfix users (my users are stored in sasldblistusers2 and I have 2.3.3 postfix version) for then to import in a new server postfix server (with 2.5.6 postfix version)? Thanks in advance. As long as you're compiling against the same Cyrus SASL, there is no need to export users when you upgrade Postfix. It will recognize the same sasldb2. If you need to transfer your sasldb2 to a new machine, it will depend on the underlying database format/version used. In many cases, you can simply copy it. But, if the formats are incompatible, you may have to dump it to text, then recreate it on the new machine.
Re: non-alpha HELO
Bill Cole wrote, at 03/13/2009 10:23 AM: Jorey Bump wrote, On 3/13/09 8:51 AM: LuKreme wrote, at 03/13/2009 07:22 AM: So I thought I'd see if anyone else thought that a helo in the form [12.34.56.789] SHOULD be allowed. I mean, as far as I recall, this is still technically allowed, right? A bracketed IP address is valid in a HELO/EHLO, but is so rare in legitimate mail that it's still worth blocking. It should be noted that this is true only for mail transport, not mail submission. For the people still supporting the antiquated model of accepting mail submission via SMTP rather than a proper port 587 daemon, it is important to make allowances for the fact that MUA's frequently have no better choice for their HELO argument than an IP literal, and sometimes even that is pretty lousy (i.e. an ephemeral RFC1918 private IP) MUA HELOs are problematic in many ways. But you're absolutely right, this is best handled by delaying this sort of check_helo_access until smtpd_recipient_restrictions, after permit_mynetworks permit_sasl_authenticated, if you support submission on SMTP port 25 on an MX server.
Re: Export User
Sasa wrote, at 03/13/2009 10:58 AM: Jorey Bump wrote: If you need to transfer your sasldb2 to a new machine, it will depend on the underlying database format/version used. In many cases, you can simply copy it. But, if the formats are incompatible, you may have to dump it to text, then recreate it on the new machine. yes, I want transfer sasldb2 users to another mail server, on my current mail server I have: cyrus-sasl-2.1.21 postfix-2.3.3 and for to create user I use: #saslpasswd2 -c -u mail.example.com -a smtpauth test On the new mail server I have: cyrus-sasl-2.1.22 postfix-2.5.6 With this configuration can I simply copy sasldb2 file from current server to new server ? It seems highly probable. It's harmless to test it. In fact, you can run this command on both machines to verify the format: file /etc/sasldb2 If you don't have an sasldb2 on the new machine, just create one by adding an entry with saslpasswd2. If they're the same type, a simple copy should work. Of course, you could just go ahead and copy it and see if it works. Remember to make backups on both machines.
Re: non-alpha HELO
LuKreme wrote, at 03/13/2009 11:53 AM: On 13-Mar-2009, at 09:04, Jorey Bump wrote: For the people still supporting the antiquated model of accepting mail submission via SMTP rather than a proper port 587 daemon, it is important to make allowances for the fact that MUA's frequently have no better choice for their HELO argument than an IP literal, and sometimes even that is pretty lousy (i.e. an ephemeral RFC1918 private IP) MUA HELOs are problematic in many ways. But you're absolutely right, this is best handled by delaying this sort of check_helo_access until smtpd_recipient_restrictions, after permit_mynetworks permit_sasl_authenticated, if you support submission on SMTP port 25 on an MX server. OK, this piqued my interest. I have 587 setup, and I also have a couple of alternate ports in the 1025+ range to deal with any users unlucky enough to be behind draconian ISPs, but I do still accept mail on port 25. In fact, I wasn't even aware that you could force users to use the submission port. Where's the read me on configuring master.cf for this, as I think it might be worth looking at. Forcing users to submit mail to port 587 basically means dropping support for relaying to external domains on port 25. This poses less of a problem now than it did in the past, since nearly all modern clients support STARTTLS on alternate ports. Essentially, you remove permit_mynetworks permit_sasl_authenticated from your smtpd_*_restrictions in main.cf, so they will no longer be exempt from the more strict checks (although a handful may still be able to send directly to the domains you handle). If you configure port 587 properly (the default in master.cf is usually fine), you can notify your users to switch. Then it's basically rinse, lather, repeat until you have a minority that need to be targeted individually. Once you've migrated users to your satisfaction, remove support from main.cf. BTW, what ISPs are blocking port 587? This is disturbingly wrong.
Re: Export User
Sasa wrote, at 03/13/2009 11:35 AM: On current mail server I have: [r...@mail ~]# file /etc/sasldb2 /etc/sasldb2: Berkeley DB (Hash, version 8, native byte-order) on new mail server I have: [r...@mail ~]# file /etc/sasldb2 /etc/sasldb2: Berkeley DB (Hash, version 9, native byte-order) ..the version is different, this is can be a problem ? Unfortunately, it might. But Berkeley DB provides decent tools for dumping databases, so you should be able to easily dump the contents on the old machine then load them on the new one. I use gdbm for sasldb2, however, so you'll need to do some research or ask on the appropriate list. I think db_dump and db_load will do the trick, but I'm not aware of the steps. Also keep in mind that it's possible to have multiple versions of Berkely DB installed, so watch out for possible conflicts.
Re: non-alpha HELO
LuKreme wrote, at 03/13/2009 04:26 PM: On 13-Mar-2009, at 10:49, Bill Cole wrote: If you have a good port 587 config in master.cf, you may need no changes there. My submission entry for a server that accepts no port 25 submission from outside the LAN is: submissioninetn-n--smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit -o smtpd_milters= (If your main.cf doesn't define smtpd_milters, the last line is unnecessary) That's nice to see. My master.cf is quite old, and the submission port info is... lemme look Oh, my 587 inet n - n - - smtpd That's it. Lemme at least change that. Here's an example for a recent Postfix: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard.
Re: non-alpha HELO
Sahil Tandon wrote, at 03/13/2009 08:36 PM: Jorey Bump wrote: LuKreme wrote, at 03/13/2009 04:26 PM: On 13-Mar-2009, at 10:49, Bill Cole wrote: If you have a good port 587 config in master.cf, you may need no changes there. My submission entry for a server that accepts no port 25 submission from outside the LAN is: submissioninetn-n--smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit -o smtpd_milters= (If your main.cf doesn't define smtpd_milters, the last line is unnecessary) That's nice to see. My master.cf is quite old, and the submission port info is... lemme look Oh, my 587 inet n - n - - smtpd That's it. Lemme at least change that. Here's an example for a recent Postfix: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject One point of clarification for others who may get tripped up by the subtle difference between these two examples. In Bill's version, smtpd_recipient_restrictions contains permit_sasl_authenticated, whereas the latter is set in Jorey's smtpd_client_restrictions. I believe one needs to permit_sasl in recipient_restrictions; at least in the context of this thread, where it is suggested that you remove permit_mynetworks permit_sasl_authenticated from your smtpd_*_restrictions in main.cf. Otherwise SASL authenticated clients will be unable to relay (probably blocked by reject_unauth_destination at RCPT TO). Quite right. My example is from a site that still has permit_sasl_authenticated in smtpd_recipient_restrictions in main.cf. If you remove that, you need to adjust the submission service accordingly: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING This is also true of smtps (port 465) if you need to support older clients: smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING It may also be unnecessary or undesirable to remove permit_mynetworks from smtpd_*_restrictions in main.cf, depending on how you're using it.
Re: Unable To Track Spam in Mail Logs = :(
Carlos Williams wrote, at 03/11/2009 11:19 AM: I just had a ticket come in regards to a user who just last week started receiving a crazy amount of spam emails that he has never had an issue with. I checked the mail logs (/var/log/mail.log) and was unable to find anything. I checked the spam emails the user still had on his client and copied the message headers: Return-Path: hangza...@yahoo.com.cn This will be logged. Received: from mail.lkpp.gov.my (unknown [219.93.25.92]) As will this IP. Now I am wondering why I am unable to find any of these messages in my logs: mail:~# cat /var/log/mail.log | grep -i 203.217.121.52 mail:~# cat /var/log/mail.log | grep -i 3B3311FA41E0 mail:~# cat /var/log/mail.log | grep -i guypatricelumu...@congo.gov Am I searching for this incorrectly or in the wrong directory? Thanks for any help! Debian logs email funny. Try this, and work from there: egrep '(hangza...@yahoo.com.cn|219.93.25.92)' /var/log/mail* If that turns up nothing, you may need to look at /etc/syslog.conf (or whatever Debian uses) to see how syslog is configured to log mail.
Re: Plus addressing not delivering to folder
Charles Marcus wrote, at 03/06/2009 02:27 PM: I want to be able to use plussed addresses in such a way that if such a message comes in and a subfolder matches the extension, the message will be delivered to that subfolder, and if there is no matching subfolder, it is just delivered to the Inbox. Cyrus IMAPd supports this behaviour.
Re: Configuration advice
Emmanuel Seyman wrote, at 03/04/2009 02:03 PM: What's the best way to do this? If I install SA on the first domain and remove the lists.example.org MX, spammers will still be able to send spam to it directly. Is setting up SA on both machines the simplest way to go? It's certainly more flexible. You can adjust SA scores on the list server in a way that might be too restrictive or inappropriate on the other.
Re: submission port requiring starttls even when set not to (Resolved)
J.P. Trosclair wrote, at 03/04/2009 04:05 PM: LuKreme wrote: On 4-Mar-2009, at 13:08, J.P. Trosclair wrote: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt Why? I didn't explicitly add it. It was a left over from the default master.cf for the postfix package on debian 5.0. It's gone and everything is good, for now. Put it back. smtpd_enforce_tls is deprecated since Postfix 2.3 and smtpd_tls_security_level should be used instead. Furthermore, you should leave it set to encrypt. Part of the value of running a submission service on port 587 is that it allows you to severely restrict connections in a way that is acceptable to ISPs, who are blocking outgoing connections to SMTP port 25. If admins begin relaxing the restrictions on port 587 without understanding the ramifications, ISPs might start blocking it, too, which is bad for residential and roaming users who need it in order to relay mail through the desired server. An important part of this is encrypting all connections to port 587. It's easy enough to set up another (local) port in master.cf that will serve your purpose (or someone might even be able to suggest an alternative approach).
Re: submission port requiring starttls even when set not to (Resolved)
LuKreme wrote, at 03/04/2009 05:24 PM: On 4-Mar-2009, at 14:33, Jorey Bump wrote: smtpd_tls_security_level should be used instead. Not if you don't want to force TLS on the submission port it shouldn't. The context is irrelevant. smtpd_tls_security_level is the new parameter that replaces smtpd_enforce_tls, which is still available for backwards compatibility. postconf(5) has this to say about smtpd_enforce_tls: This feature is available in Postfix 2.2 and later. With Postfix 2.3 and later use smtpd_tls_security_level instead.
Re: submission port requiring starttls even when set not to (Resolved)
J.P. Trosclair wrote, at 03/04/2009 05:01 PM: I'll research the smtpd_tls_security_level option further. It didn't present a problem until I started working on this specific feature with the white lists. I have created another smtpd instance to forward white listed domains to rather than trying to utilize the submission port. I felt like I was over-complicating (because of archiving with *_bcc_maps and duplicate mails) the functionality of the submission service and thus headed down a bumpy road, maybe I'm wrong about this though. At the same time the submission service seems like the ideal place to hand this mail over to for final delivery since it's intended (for us) to allow trusted clients to bypass filtering and spam checks. Yes, it can be. For example, it's perfectly reasonable to include mynetworks in the submission port's smtpd_client_restrictions, then add whitelisted hosts to mynetworks. But this is really true only for hosts under your control, and not recommended for whitelisting whole external domains. For obvious reasons, it would be insane to add gmail.com to mynetworks. Unfortunately, your originally proposed solution weakens security for all clients using the submission port, including authenticating clients. A workaround is possible with these settings: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=yes But I would discourage this approach on the public submission port, as it's best to provide maximum security by encrypting all connections. When you must relax this restriction, add another port to master.cf that you can fine-tune for the intended purpose. This also allows you to apply firewall rules that would be inappropriate for a public submission service on port 587, enabling you to lock it down tightly.
Re: submission port requiring starttls even when set not to (Resolved)
LuKreme wrote, at 03/04/2009 09:25 PM: On 4-Mar-2009, at 19:12, Jorey Bump wrote: LuKreme wrote, at 03/04/2009 05:24 PM: On 4-Mar-2009, at 14:33, Jorey Bump wrote: smtpd_tls_security_level should be used instead. Not if you don't want to force TLS on the submission port it shouldn't. The context is irrelevant. Of course the context is relevant since the original poster did not want TLS *AT ALL* on the submission port. Which syntax is right for enabling a feature he DOESN'T WANT is silliness. Please read postconf(5). The recommended syntax for disabling TLS is: smtpd_tls_security_level=none The deprecated syntax is: smtpd_enforce_tls=no The OP was using both parameters with conflicting values: -o smtpd_tls_security_level=encrypt -o smtpd_enforce_tls=no He solved his original problem by removing the recommended parameter and leaving the deprecated one. In this case, he should have removed smtpd_enforce_tls and set smtpd_tls_security_level appropriately. It is not silliness to advise him to use the recommended syntax. Nor is it inappropriate to point out the pitfalls of the proposed setting, especially when he asked for suggestions.
Re: a problem with catch-all alias handling in virtuals
Andi Raicu wrote, at 02/20/2009 04:47 AM: I don't want to be in the situation where I didn't create an account to the new server and emails that were supposed to be recieved are now, well, kind of lost; so I need a catch-all email. Anyone who decides to distribute an email address without ensuring it works deserves to lose mail. You need to focus on a policy for provisioning new email addresses and a system to support it. If you try to use catch-alls for this perceived need, you will certainly fail. But there is a problem! If I do that, then ANY email sent to company.com http://company.com, even though it has a valid user in virtual_mailbox_maps, will go to lostnfo...@company.com mailto:lostnfo...@company.com! Whatever you do, do you really want to be responsible for searching through the lostnfound account because some pinhead *thinks* it *might* contain an important message to some ambiguous nonexistent address? Do you really want to burden someone else with this task? Catch-alls are almost always filled to the brim with spam, viruses and phishing exploits. Do you want to risk any of these being forwarded by mistake? Catch-alls are also a notorious black hole for messages with typos in the recipient address, so you'll have to regularly check the account for those. It's far better for the message to be rejected so the sender is aware of the typo and has an opportunity to resend the message correctly. Anything you do to try to make this work will most likely result in an unmaintainable mess. Demand that your users only use real addresses that have been properly assigned to them.
Re: Replacing Message-Id for SASL authenticated senders
Victor Duchovni wrote, at 02/08/2009 03:37 PM: On Sun, Feb 08, 2009 at 09:08:32PM +0100, mouss wrote: No, I was referring to the Sent folder, populated by the MUA, either in a local disk or using IMAP. I know some people clever-enough to set Sent == Inbox, yes this is not very common. I do this, and also use the Thunderbird feature Place replies in the folder of the message being replied to to keep the entire thread in a single folder. This makes it a lot easier to review the thread in progress and then properly archive it. I personally have rules that tag outgoing mail into non-default Fcc folders, replies are moved there too, and correct threading is expected. Still, clearly this will do only modest harm if any for some sets of users. Some MUAs are better than others at organizing threads. Nonetheless, I'd be more than a little miffed if an admin broke threading and justified it because most users are unaware of the feature.
Re: Blocking spam/address
Nandini Mocherla wrote, at 02/06/2009 12:49 PM: I am new to postfix and thinking for a way to block the email address which does not come from that domain. For example, if someone with a @xxx.com email sends to a list it must come from a server in the xxx.com domain else it should be rejected. Is it possible to do this? Have you thought this through? For example, nearly all legitimate gmail.com messages come from a server in the google.com domain. That's just the tip of a rather huge iceberg. A rule like this will reject an enormous amount of legitimate mail. Don't take my word for it, review your mail logs and see for yourself.
Re: Name service error for name=localhost type=AAAA: Host not found
Dave (DavesTechShop.net) wrote, at 01/28/2009 07:26 PM: I am not finding any solution. Here is my error: Jan 28 19:18:23 ubuntu postfix/smtp[27317]: 13n20: to=r...@localhost, relay=none, delay=8, delays=7.9/0.01/0/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=localhost type=: Host not found) If I send to just root, it is delivered perfectly. But to r...@localhost, I get this error. And the problem is that I have services on my machine that use the @localhost type of email addressing. I'd rather not change those settings because my goal is to just get all the notifications that any thing running on my server might want to send to me. Check the output of: postconf inet_protocols If you don't need IPv6 support, set it to: inet_protocols = ipv4 in main.cf. That's the default, but maybe Ubuntu (or someone) has changed it.
Re: how to filter
Tolga wrote, at 01/27/2009 08:19 AM: Heiko Wundram yazmış: I filter on the header List-Post: mailto:postfix-users@postfix.org which catches everything (AFAICT) that comes in over the list. or by the From: line Regards, /Tolga Your own message proves this to be incorrect: From: Tolga to...@ozses.net
Re: I thought I had a send-only Postfix server, but I see someone connected to it!
MountainX wrote, at 01/27/2009 11:35 AM: In my opinion, the opportunity for Linux to rise to greater heights starts Please get off your soapbox. If you have a question about Postfix, ask it. If you don't understand the answer and have more questions, ask them. If you want to say thanks, do so briefly, but it isn't usually necessary if it adds nothing to the thread. The reason I think (hope) a discussion such as the one is not off topic is because it relates to the manner in which I (or any newbie) can expect to interact with this list in the future. It's off-topic because Linux advocacy has nothing to do with Postfix, which runs on a variety of platforms. Please restrict your comments to your original question or let the thread come to a natural close. The rest is just noise that won't help other users (including newbies) who search the archive for answers to specific questions.
Re: Blocking certain outbound domains?
Todd A. Jacobs wrote, at 01/21/2009 03:42 PM: Based on the feedback that I've gotten, I've made the following changes: smtpd_client_restrictions = check_recipient_mx_access hash:/etc/postfix/mx_access check_recipient_access hash:/etc/postfix/recipient_access check_client_access hash:/etc/postfix/domain_access check_helo_access hash:/etc/postfix/helo_access reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_helo_hostname reject_unknown_sender_domain reject_rbl_client zen.spamhaus.org permit_mynetworks reject_unauth_destination check_policy_service inet:127.0.0.1:6 Most of the suggestions were to put check_recipient_mx_access into smtpd_recipient_restriction, but I'm concerned about how that will impact the allow/deny order of the existing smtpd_client_restrictions I have in place, and which seem to be working well. Logically, it doesn't make sense to perform recipient checks before you know the recipient. One of the things I don't want kiboshed is the rules that allow mail to postmaster to go through even if other rules would disallow it. I also don't want to check the hash tables twice if I don't have to, but I don't know if there's really any performance penalty if I do. Because you're using the default smtpd_delay_reject = yes, smtpd_(client|helo|sender)_restrictions will all be evaluated at RCPT TO, so it's usually unnecessary to repeat restrictions. This is one reason people throw everything in smtpd_recipient_restrictions, in the order they want. Your configuration above risks being affected if you ever change smtpd_delay_reject to no.
Re: forcing authenticated users to use port 587?
Sahil Tandon wrote, at 01/08/2009 11:37 PM: Jeff Weinberger wrote: Also you noted: In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Does smtpd_sasl_auth_enable = no completely disable submission and prevent relaying for hosts I don't accept? or is there more I have to make sure I do? This disables submission via SASL authenticated clients on port 25. My statement was an overqualified mouthful, while Sahil's response to your followup is succinct (and correct), but only one part of the puzzle. You need to understand that authentication (establishing a user's identity) is separate from authorization (granting access to a resource). smtpd_sasl_auth_enable = yes provides a user the opportunity to establish an identity, but doesn't allow relaying by itself. That is achieved by the appropriate placement of permit_sasl_authenticated (among other things). I mention this because you have another option that may make more sense in your scenario: During migration, leave smtpd_sasl_auth_enable = yes in main.cf, but remove permit_sasl_authenticated from any of the smtpd_*_restrictions in main.cf (after you've properly configured and tested the submission service in master.cf, of course). The advantage of this is that users will be allowed to authenticate, but will not be able to relay to external destinations. This will be easier to troubleshoot, and based on the relaying denied error, you can simply instruct your users to change their outgoing SMTP to use port 587. In addition, they will probably still be able to send email to you, if your server also handles mail for your destination (or allows unauthenticated relaying to the MX that does). Once all current users have migrated, you can set smtpd_sasl_auth_enable = no, if you like (unless you want the same environment in place for new users). The danger of beginning migration with smtpd_sasl_auth_enable = no is that the users may mess up their configurations trying to fix it, and they won't have an immediate way to contact you via email.
Re: getting dns error
Sahil Tandon wrote, at 01/08/2009 10:06 PM: James D. Parra wrote: I am getting the following error when sending to the below mail server. I added the name of our internal relay server to our public dns and a ptr record, but I am still getting the error below. snip host mxi4p.craigslist.org[208.82.236.164] said: 554 5.7.1 unknown[207.47.100.34]: Client host rejected: rDNS/DNS validation failed. Please setup matching DNS and rDNS records:(in reply to RCPT TO command) snip Is there something else I need to add the postfix server? This is an internal mail relay server, behind a firewall and not accessible to the public. It only sends mail for our internal users and does not receive mail. % host 207.47.100.34 34.100.47.207.in-addr.arpa domain name pointer 207.47.100.34.static.musicreports.com. % host 207.47.100.34.static.musicreports.com Host 207.47.100.34.static.musicreports.com not found: 3(NXDOMAIN) ^^ Fix that. Or if your MX is also a relay, use that instead (either directly or as a smarthost for your internal relay): $ host musicreports.com musicreports.com mail is handled by 10 mail.musicreports.com. $ host mail.musicreports.com mail.musicreports.com has address 207.47.100.36 $ host 207.47.100.36 36.100.47.207.in-addr.arpa domain name pointer mail.musicreports.com.
Re: forcing authenticated users to use port 587?
Jeff Weinberger wrote, at 01/08/2009 12:10 AM: Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Yes, you can simply set smtpd_sasl_auth_enable = no (which is the default, so you could also remove the line, but being explicit might be more helpful in this case). You can also remove permit_sasl_authenticated from smtpd_*_restrictions, but it might be wise to leave it in place for the time being (it shouldn't cause any problems). Your submission service in master.cf should already have -o smtpd_sasl_auth_enable=yes in it. Keep in mind, however, that some users will still be able to use port 25 to send messages to domains that the server accepts mail for. To them, it may seem that relaying works inconsistently. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? The decision to restrict mail submission to port 587 depends on your needs. I manage some environments where this is enforced. I actually like the separation, but it sometimes requires additional support for legacy clients (achieved in various ways). In other environments with a more diverse and general population, I continue to allow submission on port 25, but only with mechanisms that are considered secure. You'll probably want to begin with this arrangement, as you are suggesting. It's kinder to your users, if you're not in any rush. The important thing is that you're opening port 587 (with sane settings) to support road warriors and users whose ISPs block outgoing connections to port 25. This move benefits them as much (if not more) as you.
Re: forcing authenticated users to use port 587?
Chris Babcock wrote, at 01/08/2009 03:19 AM: On Wed, 7 Jan 2009 21:10:57 -0800 Jeff Weinberger j...@jweinberger.homeip.net wrote: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Your smtpd_recipient_restrictions... Right now they're probably the same for the smptd daemons listening on ports 25 and 587 and they include one or more permit_* directives, probably permit_mynetworks and permit_sasl_authenticated. You'll remove those permit_* restrictions, except possibly permit_mynetworks from main.cf and replace them with an override (-o switch) on the submission service in master.cf. submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject Better to uncomment the default submission settings in your master.cf and work from that, if needed. In recent versions of Postfix, this is: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING Before editing the settings provided with your version of Postfix, please take time to understand what you are doing. The defaults are very sane, and rarely need adjusting. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? It's an extension of a great security model, but one of the things that makes that model work is that it has been made easy to implement. It's possible to break things like scripts that need to send mail off the server with a fairly insignificant gain in security. It's not hard to do, but you do need to know the system well to do it because it's at least 2 steps off from any of the documented deployment recipes. I'd do it for a small hobby server like mine just because it's my idea of a good time. I'd also do it for corporate situations where mynetworks includes machines that aren't in a room with a lock on the door, but not if it meant reconfiguring every PHP app and shell script that sends mail out of the company to authenticate itself. This isn't necessarily a bad thing. I've found that applications and devices with poor SMTP support deserve a security audit that often reveals other weaknesses. If they're not immediately fixable, it's useful to isolate them on a separate and secure relay while waiting for them to be upgraded or replaced.
Re: forcing authenticated users to use port 587?
Jeff Weinberger wrote, at 01/08/2009 09:27 AM: Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? Actually, smtpd_sasl_auth_enable = no means that authentication is not enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/EHLO. Attempts to authenticate will generate an error. Most modern clients are intelligent enough to detect the absence of AUTH and will not attempt to authenticate. Good ones will abort and notify the user. Bad ones might attempt to continue, in case the server will still accept the message. If the domain is a destination your server handles, it will probably accept the message, otherwise it will reject it. In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks.
Re: Question regarding reject_unlisted_sender
Bill Landry wrote, at 01/07/2009 01:11 PM: However, RFCs 2821 5321 seem to state that rejection after MAIL TO is valid and should be properly handled by the sending server. So my question is why does Postfix waits until after the RCPT TO phase before rejecting the sender address? That's merely a side effect of the default setting smtpd_delay_reject = yes. Postfix can be configured to reject at any appropriate point, if desired. The default is sane, though, because it allows access to the recipient address when troubleshooting logs. Are there issue that can arise if the receiving server rejects the message immediately after MAIL TO rather then after RCPT TO is received? s/MAIL TO/MAIL FROM/ Earlier rejections would prevent recipient addresses and possibly other useful information from being logged. You might get a slight performance boost, though.
Re: email retry problem
jittinan suwanrueangsri wrote, at 01/07/2009 02:15 PM: In our environment 1. a user can not connect to other mailserver directly such as gmail,aol etc. except our mailserver. 2. a user have right to use his/her other domain sender (aol,gmail) in message which have to relay via our mailserver.if our policy allow user to send only our sender domain we can authenticate his/her right but it 's impossible to know which sender is his/her account in gmail or aol.we can not connect to their database . 3.a user need to use dynamic ip address so we can not create allow/reject policy by source ip ,dnsbl checking or other technique base on source ip. 4. our mailserver is in situation same as previous post(retry problem).There are too many emails are pending in mailserver so it affect to other email user.email sending process is slow down because of unnecessary retry.we sure these messages are bad . It sounds like you (or your ISP) is blocking outgoing connections to port 25 and you are trying to get around this block or minimize its effect. If that's the case don't bother. Use your mail server to relay and handle mail for your own domain only. If users want to relay mail via other email service providers, they can use webmail or the submission port 587. Encouraging them to use your relay for domains you don't control will only complicate things and interfere with the delivery of the messages (as you seem to be discovering).
Re: Does a policy server exist to filter on domain age/creation?
Justin Piszcz wrote, at 12/20/2008 05:43 AM: $ whois linendim.com Record created on:2008-12-15 11:45:30.0 Domain Expires on:2009-12-15 11:45:31.0 A 1-second life domain name. What do you mean? The domain expires in one year and a second from its creation date. First, is there an existing policy server out there that checks how many days old a domain is? If so, it would probably end up working a lot like greylisting. You'd get a similar effect scoring with the SpamCop dnsbl, since it penalizes fresh domains. I know there is an RHSBL for it but this seems rather odd, if the domain has expired/etc it would be nice to filter on these statistics.. True. There's no reason to accept mail from a long-expired domain (but your example hasn't expired). [BTW, there appears to be a problem with the DNS for your domain, lucidpixels.com. Your nameservers are not responding.]
Re: how to send mail to gmail account
Jose Ildefonso Camargo Tolosa wrote, at 12/19/2008 08:47 PM: On Fri, Dec 19, 2008 at 7:19 AM, Jorey Bump l...@joreybump.com wrote: Jose Ildefonso Camargo Tolosa wrote, at 12/18/2008 06:28 AM: I think you should send more info on your config, for example: MX record for your domain. myhostname entry from main.cf these two should match. There is no requirement that these match. They are completely unrelated. I said: should. There are some spam filters which uses the hostname provided by the server and make several verifications like: + Is the hostname listed as a MX for the domain? Such a filter would be broken. MX records are used only to specify the destination for a domain's mail, not the origin. Don't take my word for it, look at your maillog. You will immediately see that the client host is unlikely to match any MX record for much, if not most, of the legitimate mail you accept (it certainly won't for gmail, hotmail, etc.). Your own message doesn't even pass this test. In Postfix, $myhostname is the default for multiple settings, as seen when running this command: postconf -d | grep myhostname Not a single one of them has anything to do with the MX record. There is absolutely no benefit in having $myhostname match your domain's MX record. Suggesting that this will solve a configuration problem is a red herring. + Does the hostname *forward* resolve to the IP I'm being contacted from? I agree that would be nice, but requiring the HELO/EHLO hostname to resolve to the client IP address would reject an unacceptable amount of legitimate mail (at least on my systems). + Does the IP *reverse* resolve to the hostname? See above. For some international email, you can't even expect the client IP address to resolve to a PTR at all (although the situation seems to be improving). Strictly speaking, it would be useful to score based on FCrDNS: http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS But that begins only with a reverse lookup on the client IP address and doesn't consider the HELO/EHLO hostname at all.
Re: how to send mail to gmail account
Jose Ildefonso Camargo Tolosa wrote, at 12/18/2008 06:28 AM: I think you should send more info on your config, for example: MX record for your domain. myhostname entry from main.cf these two should match. There is no requirement that these match. They are completely unrelated. The OP needs to describe the problem more accurately. In general, no special configuration is required to send mail to any domain.
Re: Minimal MTA/ MDA for local mail only?
Gaute Amundsen wrote, at 12/11/2008 07:25 AM: Slightly OT this, but I can't think on any other obvious place to ask, and an hour of googling turned up little. The question: What are my options if I don't want to run a full blown mail server, and really only want all mail delivered to a single local mbox or maildir? There seems to be a number for minimal sendmal replacements that do smtp only, but none that delivers locally, and I don't think procmail or maildrop can impersonate /usr/bin/sendmail directly.. Basically I run smartmontools and a number of cronjobs on my laptop and I want to get the reports and alerts, but I want to avoid the overhead of running and maintaining a full mailserver. I have a sneaky feeling that I am somehow not seeing the forest for all the trees, or my assumptions are wrong, but I can't put my finger on it.. Minimal MTAs are usually developed for use with MUAs that don't include SMTP (such as Mutt) or to easily provide a way to use a relayhost on a per-user basis (so your outgoing messages don't get bounced). Therefore, they tend not to deal with local delivery. The good news is that the MTA provided with your distribution (either postfix or sendmail) is usually trivially easy to set up for local delivery, especially if the mail is locally generated. You might need to run the daemon, but the overhead is negligible, and modern distributions improve security by having it listen only on localhost by default. If you want to support a more complicated environment (such as running a local IMAP server), you may need additional tweaks, but if you simply want to read local system notifications, you usually need nothing more than the default MTA and an MUA (mail, nail, mutt, pine, kmail, etc.). The benefit you receive is that these widely used MTAs tend to handle mail more correctly, due to years of use and development.
Re: spammers using my mailserver trough webmai
Gerardo Herzig wrote, at 12/11/2008 12:32 PM: Hi all. Im facing a ugly situation. Some spammer is using the webmail to send spam. The thing is, hes using an actual account/password (from my server)to authenticate agains the webmail, and then sending mail from UK LOTTO i...@uklotto.com...crap!! Since i have smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination This dude is authenticated, so...what can i do? Cant i restrict or check the address which is sending and forbidde those which are not of my domain? This seems easy: Simply reset the password. If it was stolen, notify the original user immediately and explain what happened. Some users share login credentials among multiple accounts, so they deserve to know in order to change the password everywhere it is used. They may also need to fix a compromised machine or be educated on phishing attacks. If it's a user that is doing the spamming, delete their account.
Re: spammers using my mailserver trough webmai
Gerardo Herzig wrote, at 12/11/2008 12:47 PM: Victor Duchovni wrote: Change the password for the compromised account. Or do you offer free sign-up? Well, yes, that an option. But seems like a partial solution. About the postfix configuration: There is anything i can do to avoid an account @uklotto (or whatever is not my domain) send mail trough my server? Crap i feel not :( That's merely a symptom of your real problem: you have a compromised account, giving the spammer full access to your resource. As long as they can authenticate, they will find workarounds to any restrictions you put in place that still allow other authenticated users to send mail. For example, you really don't want them to start using your domain in a forged sender address. You must reset the password and/or delete the account. Do it sooner than later to avoid being blacklisted.
Re: TLS Logging
Larry Stone wrote, at 11/19/2008 01:50 PM: You have a client connecting to a server with your self-signed certificate (signed by a CA of your own creation). Connections to it do not generate verification failures. Does the client have your self-created CA's root certificate on it? If so, then it can verify the self-signed certificate. By definition, a self-signed certificate is a certificate signed with its own key, not one you sign yourself. If you create your own CA and sign certificates with its key, verification of those certificates only depends on your root CA certificate being trusted. This allows you to distribute a single certificate to verify an unlimited number of signed certificates. Obviously, deploying a single self-signed certificate per host doesn't scale well. As near as I can understand, the only practical difference between certificates signed by a well-known CA and one signed by your own CA is how widely distributed you can expect the CA root certificate to be. True. For a well-known CA, you expect every Internet connected computer to have the root certificate. For a self-created CA, you can only expect to find the root certificate on client systems you've put it on (which is why I keep a copy of my self-created CA's root certificate on my keychain drive). A self-created CA root certificate, once installed on a client system, has the same status as a root certificate from a well-known CA. Yep. Which is why you shouldn't rule out a serious ass-whooping if someone catches you installing your CA root certificate in their client without permission. :) It's far better for me to create an exception for the few hosts using your CA than to unquestionably accept any certificate it has signed, setting the stage for a possible man-in-the-middle attack.
Re: stop accepting mail and clear mailq
J.P. Trosclair wrote, at 11/19/2008 08:14 PM: On Nov 19, 2008, at 6:06 PM, Wietse Venema wrote: To stop receiving mail from the network, comment out the network facing smtpd entry in master.cf, do postfix reload, and look for warnings in the maillog file. You can get a lot fancier and set up an access rule that replies with 421 Service unavailable for migration. Wietse Thanks for the info, I'll look into taking this approach. You only mention your MX needs. If the server also offers submission service, you will need to plan carefully. In order to be transparent, your users shouldn't need to change client configuration. If you can afford to deny access to your human users during the outage, you may still need to accommodate web applications or mailing lists. Some of these do not fail gracefully when there is a connection error, so make sure the admins are aware of the downtime so they can plan accordingly.
Re: Backscatter issues with non-delivery notifications
Dave Buchanan (Abo Ltd) wrote, at 11/03/2008 10:32 AM: Dear postfix users I have re-configured our postfix mailservers to remove catch all aliases to remove the ammount of mail accepted. I know have one more issue to resolve with respect to non delivery notifications - backscatter the setup is as follows [EMAIL PROTECTED] - [EMAIL PROTECTED] (demon.net is an uk isp) This is what happens to an e-mail that has spam / virus etc from Mail is accepted by our servers for delivery and then passed on to [EMAIL PROTECTED] The demon.net mailserver rejects this mail with a 550 error our mailserver then sends a non-delivery notification to the sender If the sender has been dreamed up by the spammer etc then they receive unwanted mail I would like to know how to turn these non-delivery e-mails off in postfix Forwarding is a particularly sticky issue, because it was once a relatively useful feature. These days it's a lot more trouble than it's worth, so avoid it whenever possible. If you can't do that, then you need to improve your own antispam defenses so your server is the one rejecting the message during the SMTP session. This will have more benefits in the long run than trying to selectively disable bounce notifications. The rule of thumb is to try not to accept messages that can't/won't ultimately be delivered. Also keep in mind that there are alternatives to forwarding. There are many client side solutions that enable you to automatically move mail from one account to another.
Re: Check MX entry before virtual domains maps
M. wrote, at 11/03/2008 01:51 PM: 4. user can add *any* domain he wants to my postfix's virtual domains maps by perl script. If that particular domain is listed in virtual domains maps postfix will not check MX record. I want to avoid it. I need to force postfix to use DNS before checking internal maps. This will break troubleshooting (I migrated an MX this weekend, and relied on the ability to locally test mail delivery before changing the MX in DNS). You need to improve your provisioning process: - When you add a destination, require proof of domain ownership (confirmation from one of the contacts in the whois record, if possible). - Once ownership is verified, add the user and update a table that lists which domains they can manage. Modify your script to restrict users according to this table. - Separate your MX from your submission service. This enforces MX lookups for outgoing mail, so that messages are relayed to the proper server. It also prevents mail from being sent to your server if the domain changes its MX record without notifying you.
Re: Check MX entry before virtual domains maps
Wietse Venema wrote, at 11/03/2008 03:06 PM: M.: On Mon, 2008-11-03 at 19:32 +0100, mouss wrote: and the problem is? If they control the domain, then you have no problem! OK, I will try to explain that by example: 0. user buys domain mydomain.com 1. user adds mx record mailserver.com to his domain 2. user adds (by perl script) entry to virtual domains maps in my postfix (mailserver.com) to inform postfix that it is final destination for this domain. Before allowing step 2 to proceed, your provisioning system should check that your system is listed as MX server for this domain. It makes no sense to do that check upon every mail transaction. Wietse Although checking the MX record before provisioning would provide the ultimate verification, it would expose the domain to the possibility of lost mail, since it requires the customer to change the MX before the destination is ready to accept mail (resulting in a permanent error). This could cause problems if the customer is migrating from a working system (but is obviously less of a problem if this is the first MX for the domain and addresses aren't in circulation, yet). It seems to me that, for many cases, best practice mandates that the MX record should not point to the destination until it is ready.
Re: Check MX entry before virtual domains maps
M. wrote, at 11/03/2008 03:41 PM: On Mon, 2008-11-03 at 15:26 -0500, Jorey Bump wrote: Although checking the MX record before provisioning would provide the ultimate verification, it would expose the domain to the possibility of lost mail, since it requires the customer to change the MX before the destination is ready to accept mail (resulting in a permanent error). This could cause problems if the customer is migrating from a working system (but is obviously less of a problem if this is the first MX for the domain and addresses aren't in circulation, yet). It seems to me that, for many cases, best practice mandates that the MX record should not point to the destination until it is ready. Yep, this is exactly what I was thinking about ;) Maybe there is workaround to this problem using transports, relays or whatever? Separating your MX from your submission service still appears to offer the best protection. There are multiple ways to achieve this, depending on the flexibility you require. This makes your MX less likely to ever need to relay to an external domain, so its own configuration wouldn't cause conflicts. Your submission service would always resolve the destination MX, and since it's not an MX itself, it wouldn't interfere, either. I recently had a client experience the type of trouble you're describing. Their developer partially configured DNS and mail at another host, but gave up when it proved to be too complicated. As a result, DNS for the domain was hijacked for all customers of that hosting company (my DNS server was still the SOA, so the rest of the Internet wasn't affected). Now the developer and other important domains could no longer communicate with my client, as they were using the hosting company's resolver, which pointed to their own MX, which rejected the unknown users (fortunately). Once I determined the problem, the developer deleted the account, and everything started working again. Separation of the MX and submission service (each using a resolver independent of the hosting company's authoritative SOA servers) would have prevented this mess. This approach will help with your original problem, but you'll still need to improve your provisioning process, so your users can't hijack other domains.
Re: Virtual Alias Rejection issues
Dave Buchanan (Abo Ltd) wrote, at 11/02/2008 02:03 PM: virtual_alias_domains = domain_one.tld domain_two.tld virtual_alias_maps = hash:/etc/postfix/virtual /etc/postfix/virtual contains [EMAIL PROTECTED][EMAIL PROTECTED] @domain_two.tlddomain_one.tld Mail to [EMAIL PROTECTED] is accepted and delivered as expected Mail to [EMAIL PROTECTED] is rejected in the original conversation as expected However Mail to [EMAIL PROTECTED] is accepted in the original conversation but then later bounced It appears the the conversion from [EMAIL PROTECTED] - [EMAIL PROTECTED] is not runnign during the original conversation - which would be (in my humble opinion) a better way to reject the message Am I missing something From virtual(5): @domain address, address, ... Redirect mail for other users in domain to address. This form has the lowest precedence. Note: @domain is a wild-card. With this form, the Postfix SMTP server accepts mail for any recipient in domain, regardless of whether that recipient exists. This may turn your mail system into a backscatter source: Postfix first accepts mail for non-existent recipients and then tries to return that mail as undeliverable to the often forged sender address. Don't implement wild-cards unless you can assure the message will be delivered to a valid recipient (who will then receive a lot of spam).
Re: Which FileSystem do you use on your postfix server?
Victor Duchovni wrote, at 10/30/2008 12:44 PM: Past reports of ReiserFS on this list indicate that it falls short of reasonable (i.e. perfect) data integrity expectations. I also value data integrity over performance and will add that XFS never made it out of my punishment closet into a production system. On Linux, I use ext3 and have never lost data, even in the worst of conditions.
Re: Best anti-spam
Richard Foley wrote, at 10/22/2008 07:56 AM: On Wednesday 22 October 2008 01:27:51 Terry Carmen wrote: check_client_access=regexp:/etc/postfix/spam_ip_regex spam_ip_regex file: /[ax]dsl.*\..*\..*/i 450 AUTO_XDSL Email Rejected. You appear to be connecting from a Dynamic IP address. /client.*\..*\..*/i 450 AUTO_CLIENT Email Rejected. You appear to be connecting from a Dynamic IP address. /cable.*\..*\..*/i 450 AUTO_CABLE Email Rejected. You appear to be connecting from a Dynamic IP address. /dial.*\..*\..*/i 450 AUTO_DIAL Email Rejected. You appear to be connecting from a Dynamic IP address. This looks fairly useful. Does anyone else have any experience with this approach, who might be able to offer insight into whether it's valid or not? You can see for yourself: egrep '[ax]dsl.*\..*\..*' /var/log/maillog These expressions seem a little too simple, since they could easily produce false positives (smtp.sundial.co.uk, for example). You'd want to find something that is tuned to target common residential host names. Is it valid? That's open to debate. DNS is hard enough to grok without mandating which names are acceptable for specific services, but you're free to adopt whatever local policy you want. Caveat emptor.
Re: Finally blocking some spam
Joey wrote, at 10/17/2008 09:14 PM: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of j debert Sent: Thursday, October 16, 2008 11:26 AM To: postfix-users@postfix.org Subject: Re: Finally blocking some spam That's still too simple. You're simply counting connections again. How many of those connection attempts are hosts retrying (sending the same mail)? You do not have the data to tell you what is going on. [snip] Get rid of your tainted IP and ensure that your domain is also not tainted. Once a domain or username is tainted, it seems to stay that way apparently forever. Hi Jorey, No, that was J Debert. :) Any suggestions you have to help me reduce the load on the servers, and the junk in the mailbox are welcome, and I can assure you I will try just about anything as you can see by my blanketed IP method which for reference has reduced spam by over 75%, and yes blocked a few legit users. Analyze. You're right that stopping abusers at the firewall can help to reduce load. But the main.cf you posted has everything but the kitchen sink in it. It probably wouldn't hurt to trim it a bit, if there's little return. For example, an RBL that doesn't block much and is slow can add latency that will hurt overall performance. Some checks are more expensive than others, and need to earn their keep.
Re: Finally blocking some spam
Joey wrote, at 10/13/2008 11:57 AM: For us greylisting was a problem because it put a big delay on email when you were sitting waiting for a message from someone you were talking to, but that catches A LOT of email. Consider Nolisting. It doesn't have the delay associated with greylisting, and will turn away the first wave of connections from spambots: http://nolisting.org If your concern is reducing load on your server, this will help decrease obviously spammy connections without introducing much overhead at all. Basically you take a list of IP blocks by country or manual lists like so: 91.124.0.0/9 92.113.0.0/9 92.112.0.0/9 83.110.0.0/9 217.132.0.0/9 71.0.0.0/8 These above connected to my server over the past 24 hours about 4K times. You feed these into iptables like so iptables -A INPUT -s 91.124.0.0/9 -p tcp -j LOG --log-prefix SPAM-BLOCK-CIDR-LIST_NAME_HERE iptables -A INPUT -s 91.124.0.0/9 -p tcp -m tcp --dport 25 -j DROP you can then tail /var/log/messages and see how many times you get SPAM-BLOCK working. I wrote a script to tail messages and count the amount of times SPAM-BLOCK entry shows up. When I run that script I get the original line from messages along with the first part of the line which shows: [RunTime:20 seconds]--[Spam:242]--[MsgHour:43560.00]-- Original Message here That's how I know the numbers I represented in my email. Here is an example of an additional line which is generated by a similar application tailing maillog: -[MsgHour:4947.95]--[ TMsg:6644]---[GMsg:227 3%]---[TSpam:6416 97%]-[RunTime:1 hour, 20 minutes and 34 seconds]--- While I did check that I was getting spam from these sources in some cases, I went blindly to those top spam countries. My clients are good about letting me know when they aren’t getting email. It's no surprise to anyone here that the overwhelming number of delivery attempts are spam. As a result, it's easy to fool yourself into thinking you're making a dent against spam when you're actually exposing ham to increased risk. I can tell you from experience that outright blocking of countries is a Bad Thing. It's unsustainable and will eventually come back to bite you. This doesn't mean that all networks are the same. When I developed Unlisting, I discovered it was too aggressive for general use. But I have been using Selective Unlisting with some success, targeting networks with bad reputations, while allowing most of the legitimate mail through. If you try Nolisting and are happy with the results, consider implementing Selective Unlisting (but be warned that the configuration is far more complex and must be implemented with care): http://unlisting.org http://unlisting.org/selective.html Selective Unlisting relies on the ipt_recent module, and requires that the first MX always rejects, and the second MX only accepts connections if the first has been tried: iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.3 --dport 25 -m recent --set --name UNLIST -j REJECT --reject-with tcp-reset iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.4 --dport 25 -m recent --rcheck --name UNLIST --seconds 4000 -j ACCEPT iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.4 --dport 25 -j REJECT --reject-with tcp-reset In this example, 10.0.0.0/16 is the suspect network, 192.168.1.3 is the primary (nonfunctioning) MX, and 92.168.1.4 is the secondary (functioning) MX. This is most easily set up on a single machine, but it can also be configured on a transparent filtering bridge. You can target as many networks as you like. But read the documentation carefully and understand the caveats. And definitely try Nolisting first, along with other techniques that are lightweight and safer than country blocks.
Re: Finally blocking some spam
Joey wrote, at 10/13/2008 01:42 PM: You reach a point where the money we think we are profiting from services sucks up all our time and resources and somehow we have to reduce that overhead and SPAM. Imagine that we are blocking millions of spam messages a month through various methods and we have clients complaining about spam... what are we to do. It gets really old. No argument here. :) Of the remaining spam that gets past my defenses, nearly all of it could be stopped by the following: 1. Require Forward Confirmed reverse DNS (FCrDNS), where the IPs must match in a IP - name - IP lookup. 2. Require reverse DNS (rDNS), where the connecting host must have a PTR record, returning a (valid) host name in an IP - name lookup. 3. Require encrypted connections via STARTTLS. FCrDNS offers a lot of promise, but if Network Solutions can't even get it right (when its parent company, Verisign, controls a huge chunk of DNS), there's little hope that other sites will. I'd like to apply the ipt_recent module to hosts without FCrDNS, but there is little desire for filter developers to base rules on realtime DNS lookups, since it can introduce significant overhead and a host of other serious problems. Selective greylisting aimed at FCrDNS offers some hope, however, as many of the offenders don't appear to retry. Many school and government sites (not to mention China) can't seem to configure rDNS and FCrDNS properly. I have given up trying to contact offending sites. Too often, they decide the solution is simply to drop the recipient from a mailing list, instead of correcting their DNS records to improve the robustness of their mailings. It's a shame, because things got pretty quiet on my test domains during the weeks I implemented reject_unknown_(reverse_)client_hostname. Requiring encryption is a pipe dream, and as Wietse has mentioned, introduces a greater risk of exposing bugs as a result of linking to a large base of external code.
Re: Finally blocking some spam
Joey wrote, at 10/13/2008 05:10 PM: I can only tell you that in 4 days we have blocked at the firewall level ( on only 1 server ) 161,166 connections from Poland 1,184,747 connections from Turkey 418,162 connections from Russia 53,656 connections from Czech 1,613,636 connections from Asia 129,428 connections from UK Just for reference on one of the other servers 2,193,894 connections from Turkey. I don't think anyone can argue that these numbers are not the pattern of NORMAL servers, or of legit email. We maybe support 400-500 users total! No way 1 Million legit messages are coming in from Turkey today, this week or even this month. connections != messages Make sure you count the hosts, not the number of packets that were attempted. In many cases, each host is only trying to send one message. Blocking can skew the numbers (but the ones you report are still rather large). Consider that your IP address has become tainted. If you've been using it for a long time (or inherited an IP with a history), there is a possibility that a number of these attempts are automated and not even aimed at your users. In that case, try moving to a new IP address with no SMTP history. You might also monitor the target recipients, to see if an address (or domain) has become an attractor for some reason. This can be done maliciously, and is enough of an excuse to retire the address.
Re: TLS on port 25
Jake Vickers wrote, at 10/08/2008 10:49 AM: Are there good reasons to NOT use TLS on port 25? (ie: in master.cf: -o smtpd_use_tls=no) Curious as to if it breaks things for certain clients or something. There's a good reason not to *require* STARTTLS on port 25, if you want to allow connections from client MTAs that don't do TLS. I configure opportunistic TLS at the global level in main.cf: smtp_tls_security_level = may But I require it for the submission service in master.cf: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Note that smtpd_use_tls and smtpd_enforce_tls have been obsoleted by smtpd_tls_security_level: http://www.postfix.org/postconf.5.html#smtpd_tls_security_level There are probably cases where specialized servers handle high traffic mail that doesn't require encryption, in order to reduce the computational overhead and stretch the hardware dollar. Personally, I think there's a strong case for enforcing encryption, which could offer some relief from spambots (albeit temporary, until they catch up and add TLS functionality). Unfortunately, this is currently not feasible if you want to receive mail.
Re: Fighting SPAM
Marky Yehezkiel (SNC) wrote, at 10/06/2008 10:17 PM: I just wondering is there any way in postfix that can check port 25 of sender is open or not. Why do you assume that a legitimate relay must also accept connections on port 25? There's no requirement that an MX must also be the source of outgoing mail for a domain. The method you propose would reject mail from many large ESPs (such as Gmail) or a number of mailing list services.
Re: SASL configuration woes
Stephen Holmes wrote, at 10/03/2008 11:44 AM: Hi PostFixers, I'm now running postfix/dovecot/mysql in SUSE Linux Enterprise 10 SP2 and I wanted to secure the SMTP connections. I've tried to follow one or more tutorials, but so far to no avail. The server is up and running and Thunderbird seems to use SMTP over TLS but when I issue a telnet localhost 25 I get... 220 mail.gallopinggreen.com NO UCE ESMTP EHLO localhost 250-mail.gallopinggreen.com 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN I can see the STARTTLS, but not the AUTH statements. My postconf output is.. smtpd_tls_auth_only = yes You've wisely configured postfix to offer AUTH only via STARTTLS, so it won't appear until the session is renegotiated and encrypted. telnet is not up to troubleshooting this task. You've confirmed with a client that it works, but you can also use openssl: openssl s_client -starttls smtp -debug -connect localhost:25
Re: Use of X509v3 Subject Alternative Name
Victor Duchovni wrote, at 10/03/2008 12:35 PM: On Fri, Oct 03, 2008 at 10:22:59AM -0400, Jorey Bump wrote: I'm curious about the use of X509v3 Subject Alternative Name in certificates, and if they pose any problems when used in production. No, these are preferred to CommonName when used to verify DNS names. See RFC 5280. For example, if I obtain a certificate with the Common Name of www.example.com for primary use over HTTP, and add an X509v3 Subject Alternative Name of mail.example.com for dual use over SMTP (server) and HTTP (for webmail), will there be issues? Is support widespread enough to safely implement this approach (assuming I can get a commercial cert issued)? Who do you expect to be checking your SMTP certificate? (Hint: most MTAs cannot be configured to check it, and those that can be, are not so configured by default). Currently, my smtpd_tls_cert_file is generated by a local CA and other MTAs connect to it without any problem, even though the CN (mail.example.com) doesn't match the MX name (mx.example.com). I haven't generated a local cert that uses DNS Subject Alternative Names, so I'll have to give that a test. However, user mail clients will attempt to verify the certificate (for SMTP and IMAP), as will web browsers (for HTTPS). Since this is becoming increasingly more difficult to overcome for nontechnical users as these clients become more strict, I'm wondering if this approach is feasible, compared to deploying multiple or wildcard certs. Will most modern clients recognize the correct name, or is support still lacking? This said (or asked rhetorically), when Postfix is checking certs it will verify subjectAltName. Sendmail can only verify the CN (you can probably count on one hand the Sendmail sites with CN constraints in their access files). So, MTA verification isn't much of an issue today, but the safest approach would be to use the most likely name sought by a connecting MTA as the CN, then list it and additional names as DNS Subject Alternative Names, correct? Deciding which name to use as the CN is one of the reasons I'm asking.
Re: Stupidly simple problem...
Kurt Buff wrote, at 09/25/2008 12:47 PM: I'm getting messages in /var/log/maillog about mail looping back to myself, and the mail is discarded. Sep 25 03:01:21 loki postfix/smtp[24894]: 021951A4CEC: to=[EMAIL PROTECTED], relay=none, delay=0.01, delays=0.01/0/0/0, dsn=5.4.6, status=bounced (mail for loki.example.com loops back to myself) Sep 25 03:01:21 loki postfix/qmgr[58371]: 021951A4CEC: removed postconf -n mydestination = mydomain = example.com myhostname = loki.example.com Try: mydestination = $myhostname, localhost /usr/local/etc/postfix/aliases root: [EMAIL PROTECTED] The mail is addressed to [EMAIL PROTECTED], so you should accept it. Your alias will forward it to [EMAIL PROTECTED]
Re: How spammy is my mail?
Neil wrote, at 09/24/2008 06:19 AM: What's the best way to see what spam traits my mail server and mails are exhibiting? Is there some place I can submit a mail or send a test mail and get back some sort of report, or the like? Check your IP address to see if it's on any RBLs: http://openrbl.org/ Check your DNS for any misconfigurations: http://www.intodns.com/ AFTER you've read up on the subject enough to test if your server is an open relay (for example, by using telnet from an *external* network), confirm your findings by checking with an external tool: http://www.abuse.net/relay.html It's not wise to implicitly trust any 3rd party open relay test. The onus is on you to attempt secure your system first.
Re: postfix accepting mail for juno.com
Jason Noble wrote, at 09/11/2008 08:08 AM:
On Wed, 2008-09-10 at 16:35 +0200, mouss wrote:
Jorey Bump wrote:
Set up a separate DNS server if you want to block ad sites for your your
LAN users. I do this, but I simply make the local DNS server
authoritative for the offensive domains (or subdomains) and point them
all to the same zone file, which has no A records defined. Why anyone
would point these to 127.0.0.1 or any other IP address is beyond me.
and is even dangerous. it allows a stranger to make you do a query on a
local service. with FCSR and XSS attacks being so common these days,
this is unwise. What would happens if say you get to click on
http://127.0.0.1:1234/disable_firewall
?
this is also the reason why it is not recommended to put private IPs in
public dns zones (foo.example.com - 192.168.1.2).
What about just pointing to 0.0.0.0
That can be even worse, since 0.0.0.0 is reserved for the default
network. See RFC 3330 (http://tools.ietf.org/html/rfc3330#section-2):
0.0.0.0/8 - Addresses in this block refer to source hosts on this
network. Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network [RFC1700, page 4].
Don't be surprised if you ping 0.0.0.0 and it hits 127.0.0.1 (depending
on the platform).
On my local DNS server (using bind) at the end of named.conf, I put this
line:
include /var/named/dummy.conf;
dummy.conf defines the zones of various spamming domains, all pointing
to the same file, with my server set as master:
zone example.com {
type master;
file master/dummy;
allow-transfer { localhost; };
};
zone adserver.example.net {
type master;
file master/dummy;
allow-transfer { localhost; };
};
/var/named/master/dummy is a simple zone file with no A records defined,
so lookups on the domain will return nothing, and subdomains will always
fail with NXDOMAIN:
$TTL1d
@ IN SOA ns.localdomain.hostmaster.ns.localdomain. (
2006121001 ; serial
8h ; refresh
2h ; retry
7d ; expire
1h ; default_ttl
)
;
; Name servers
;
@ IN NS ns.localdomain.
But this is getting off-topic. Note that this is only for serving
recursive lookups to my local network. I would never have Postfix or any
other important service use this for a resolver.
On a related note, one of the authoritative DNS servers (ns.voloper.com)
for your domain (polezero.com), allows recursive lookups from the
Internet. That's crazy. You should drop it or ask voloper.com to disable
recursive lookups.
Re: ldap+cyrus+virtual_mailbox_maps :no mailbox associated
mouss wrote, at 09/06/2008 05:12 AM: TOUZEAU DAVID wrote: pc-touzeau.klf.fr[/var/run/cyrus/socket/lmtp]: RCPT TO:[EMAIL PROTECTED] so you see. postfix says RCPT TO:[EMAIL PROTECTED]. Sep 6 10:55:18 pc-touzeau postfix/lmtp[19755]: pc-touzeau.klf.fr[/var/run/cyrus/socket/lmtp]: DATA Sep 6 10:55:18 pc-touzeau cyrus/lmtpunix[19756]: verify_user(user.david^t) failed: Mailbox does not exist and cyrus doesn't like the recipient. (looks like the '.' became a '^' in the log or maybe elsewhere?). By default, Cyrus IMAPd does not allow . in user or folder names, and will convert it to ^. Such recipient addresses can be supported by using aliases that point to users without a . in the name. This is what the OP is trying to do, and needs Postfix to perform the lookup via LDAP to make the translation. I don't use LDAP, but it looks like it's time for postconf -n.
Re: FW: Virtual Interface
Marcel Grandemange wrote, at 09/02/2008 01:48 PM: If postfix could simply send mail from the virtual address our issues would be solved http://www.postfix.org/postconf.5.html#smtp_bind_address
Re: FW: Virtual Interface
Marcel Grandemange wrote, at 09/02/2008 02:45 PM: I tried according to docs set bind address to 127.0.0.1 and the virtual ip, It still sends mail out main interface. You asked how to bind the postfix smtp client to your virtual IP address, which is described here: http://www.postfix.org/postconf.5.html#smtp_bind_address interface != IP address I don't see how controlling the origin interface will solve your problem, unless you've described it poorly. I have used smtp_bind_address to control the IP address of outgoing SMTP connections on a server that had another blacklisted IP address. It worked fine, if this is what you are attempting to do.
Re: master.cf question with SASL
Jake Vickers wrote, at 09/01/2008 10:08 AM: I currently have all my users using the submission port for outgoing mail. They cannot send on port 25 at this time, and according to all of the online tests I have tried I am not an open relay or backscatter sprayer. My master.cf currently shows: smtp inet n - - - - smtpd -o smtpd_use_tls=no -o smtpd_sasl_auth_enable=no -o content_filter=smtp-amavis:[127.0.0.1]:10024 If I change smtpd_sasl_auth_enable to yes, it allows some devices (handhelds, Treo, etc.) to send on port 25 if authenticated, but I want to make sure that this does not turn me into a relay or anything before doing so. I have attempted to relay through it while it's enabled, and they were denied. I decided to err on the side of caution and check with the experts here before just doing it in case there were any pitfalls or gotchas I do not know about. In addition to what mouss said, be sure to allow only secure authentication mechanisms, so that passwords aren't sent in the clear. You indicate this is for road warriors, who may not always be on a secure network. Ideally, you'll want to encrypt the entire communication, if the target devices support it.
Re: [OT] Using [EMAIL PROTECTED] [was: best way for website sending emails]
Charles Marcus wrote, at 08/26/2008 08:57 AM: On 8/26/2008, Robert Schetterer ([EMAIL PROTECTED]) wrote: as far i know blacklist reputation is only related to answering hostmaster@ postmaster@ abuse@ webmaster@ by rfc My understanding is the RFC only requires postmaster and abuse to be valid, NOT webmaster - and I've NEVER used hostmaster for anything... I've used it for DNS issues, since the hostmaster address is commonly used as the contact in SOA records. I don't think it's an RFC requirement to use 'hostmaster@', though, so one should check first: $ dig +short -t SOA example.com dns1.icann.org. hostmaster.icann.org. 2007051703 7200 3600 1209600 86400 Note that the '@' is replaced by a '.' in the email address. In any case, I think blacklisting based on hostmaster contact would be problematic, since an SOA record can exist at an arbitrary level. You'll ultimately find one, but you need to be careful how you apply this information so you don't punish the wrong party.
Re: SASL query
Patrick Ben Koetter wrote, at 08/14/2008 08:22 AM: The order in which mechanisms are listed in $mech_list or in which they are announced as SMTP capability is irrelevant. The client chooses the best mechanism by it's own logic. Note that this has become a blessing from a support point of view, because modern clients will rarely send passwords in the clear if a better mechanism is available. Many users are stabbing in the dark and stop at the first configuration that works, so this approach offers a little more protection.
Re: mail aliases spam
John Heim wrote, at 08/14/2008 02:09 PM: postconf on the mta: smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_unknown_sender_dom ain, permit_mynetworks, reject_unauth_destination, check_sender_access hash:/etc /postfix/access, permit Try this: smtpd_recipient_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain permit_mynetworks reject_unauth_destination check_sender_access hash:/etc/postfix/access reject_non_fqdn_helo_hostname reject_invalid_helo_hostname warn_if_reject reject_unknown_reverse_client_hostname warn_if_reject reject_unknown_client_hostname check_helo_access pcre:/etc/postfix/helo reject_rbl_client zen.spamhaus.org reject_rbl_client insert favorite RBL here In my experience, reject_unknown_reverse_client_hostname and reject_unknown_client_hostname produce false positives. However, the numbers have gone down, and several members of this list have reported the risk to be acceptable, so I am rejecting them with pretty good results. I am reporting misconfigurations to the legitimate sites and crossing my fingers. I've prepended warn_if_reject to these lines, so you can evaluate them before committing. I do *not* recommend changing unknown_client_reject_code from its default of 450. While it may result in more log lines from retries, I can testify from experience that DNS errors do happen and you don't want to permanently reject mail due to a transient DNS failure. Use the check_helo_access map to effectively catch some popular obvious spam. In /etc/postfix/helo, I have (among others): # Block illegal unbracketed IP addresses and bare numbers (including negatives) # Examples: 192.168.1.34, 12345678, -12345678 /^[\d\.-]*$/ REJECT Unacceptable hostname in helo # Block legal IPv4 address literals (bracketed IP addresses) due to surge in spam # NOTE: Make sure your site does not need to support address literals in HELO # Example: [192.168.1.34] /^\[[\d\.]*\]$/ REJECT Policy prohibits address literals in helo # Block localhost (unusual in HELO) /^localhost(\.localdomain)?$/ REJECT Unacceptable hostname in helo In addition, my first line of defense is Nolisting, which still works effectively against certain zombies and helps to reduce load upfront, using any packet filter: http://nolisting.org/ I supplement this with Selective Unlisting (which relies on iptables at the moment): http://unlisting.org/selective.html With all of these in place, you are in a good position to add some RBLs without overloading them. At the very least, consider zen.spamhaus.org, which to date has been safe enough to use for outright rejection (others you may want to continue to score in SA).
Re: Question with postfix and DNS and newegg.com e-mails.
Justin Piszcz wrote, at 08/08/2008 07:53 AM: On the server w/ postfix: $ host 38.119.56.160 160.56.119.38.in-addr.arpa domain name pointer mta700.testemail.newegg.com. 160.56.119.38.in-addr.arpa domain name pointer mta700.email.newegg.com. When it re-connected (after greylisting, then it works, what's going on)? Aug 8 07:46:30 l1 postfix/smtpd[10502]: connect from mta700.email.newegg.com[38.119.56.160] Multiple PTR records tend to be returned in a round robin fashion: $ host 38.119.56.160 160.56.119.38.in-addr.arpa domain name pointer mta700.testemail.newegg.com. 160.56.119.38.in-addr.arpa domain name pointer mta700.email.newegg.com. $ host 38.119.56.160 160.56.119.38.in-addr.arpa domain name pointer mta700.email.newegg.com. 160.56.119.38.in-addr.arpa domain name pointer mta700.testemail.newegg.com.
Re: Question with postfix and DNS and newegg.com e-mails.
Please keep responses on the list: Justin Piszcz wrote, at 08/08/2008 10:27 AM: On Fri, 8 Aug 2008, Jorey Bump wrote: Justin Piszcz wrote, at 08/08/2008 07:53 AM: Multiple PTR records tend to be returned in a round robin fashion: $ host 38.119.56.160 160.56.119.38.in-addr.arpa domain name pointer mta700.testemail.newegg.com. 160.56.119.38.in-addr.arpa domain name pointer mta700.email.newegg.com. $ host 38.119.56.160 160.56.119.38.in-addr.arpa domain name pointer mta700.email.newegg.com. 160.56.119.38.in-addr.arpa domain name pointer mta700.testemail.newegg.com. So there is no way to make it lookup multiple records to allow the whitelisting to go through the first time? Besides allowing IPs/are there any work arounds you are aware of? Based on your log samples, this doesn't seem to interfere with the delivery of the message. What are you trying to work around? In any case, it's a remote configuration problem. You're better off contacting the other domain to let them know of the problem. Trying to adapt your configuration to the misconfigurations of others grows old soon.
