postfix clustering
Hello, I want to use postfix for active/active mode. Here is my dns settings: mycompany.com MX 10 first.mycompany.com mycompany.com MX 10 second.mycompany.com "first" and "second" machine are located in the different physical location I have two issues here: 1) where should I point my pop server? If I point to first.mycompany.com, any mails received in second.mycompany.com cannot be viewed? 2) is there a better way to synchronize the mails in first and second mail server? it will be good if one server is down and there is no disruption. I checked the documentation regarding the setup for postfix for multiple mx records, but I am not sure how these two problems can be solved. thanks a lot for the help in advance. Peter
Re: postfix clustering
Hi Victor, thanks for your response. > > I want to use postfix for active/active mode. > > No, you want to cluster your mailstore (IMAP, POP, ...). > This is not > Postfix. Multiple Postfix MX hosts do not need to be > clustered, the > SMTP design automatically load-balances multiple MX hosts. That is true. It might be easy if two mail server (with MX record) are located in the same physical location. We can use a different server (imap store) or shared storage for storing the mails for two mail servers. but if the mail servers are located in a different location, it will be hard to maintain such a shared mailstore. Peter
Re: postfix clustering
Hi Stan, > > I think Victor meant "not" a Postfix issue. If you > want to build a mail > store cluster over a WAN link, start your reading here: > > http://www.drbd.org > http://sourceware.org/cluster/gfs/ > > The combination of these will allow you to accomplish your > cluster goal. > Depending on the aggregate write bandwidth of your MTAs > and delete b/w > of your POPD, you may need a site-to-site link of anywhere > from 10Mb/s > to 100Mb/s, or maybe even more. If your two servers > are located in > buildings on the same campus and connected via 100/1000Mb/s > ethernet > then this solution will work very well. If your two > servers are located > in two internet colocation facilities and your b/w is > limited to 10Mb/s > or less, RTTs are unstable, etc, then this solution may not > work well > for you. Mirroring a disk over a network requires a > stable quality network. I agree with your point. the above solution should work well if the active/active server are located in the same location. for the machines in different data center, there is no guarantee of speed. also, making the server run in a different data center is fail-over protection solution. using rsync is a way to synchronize the storage. however, multiple MX record only works well if pointing to servers in the same data center sharing the same storage for imap. thus, a valid solution is to change the IP address of imap server when failover is required. but the dns propergation might take up to three days. is there a better alternative? guess it is something beyond postfix to handle. not sure how postfix users will handle such an issue? Thanks. Peter
Re: postfix clustering
Hi Stan, > 1. What are your specific failure concerns with your > primary site? > Network failure? Host failure? Storage hardware > failure? You have a great suggestion assuming the data center functions well. the data center primary site failure means that the data center itself failed, meaning the host machine/storage/network are all in-accessible. > Maybe a good question for you to ask of the members of this > list at this > point is: > > How many OPs here run with a multi site IMAP cluster setup > with a > physically distributed mail store, either via replication > or a cluster > filesystem over a wide area network? > That is a good question. It is something I am looking for. however, if not going for expensive cluster filesystem over a wide area network, one simple way is to rsync every 5 minutes to copy over a backup serer in another data center and a quick dns change if the primary data center failed. The TTL in DNS settings can be 5 minutes. Peter
Re: postfix clustering
- > > Hi Stan, > > > >> 1. What are your specific failure concerns > with your > >> primary site? > >> Network failure? Host failure? Storage > hardware > >> failure? > > > > You have a great suggestion assuming the data center > functions well. > > > > the data center primary site failure means that the > data center > > itself failed, meaning the host > machine/storage/network are all in-accessible. > > You seem to be looking at this from a macro point of > view. For an > entire datacenter to "fail" you're looking at something > like a natural > disaster (hurricane, earthquake, tornado, flood, lightning) > destroying > the facility, or all power and comm lines into it. > The probability of > these things is very low, assuming the datacenter was > located, designed, > and constructed properly. I am a little surprised about your common sense for the data protection. obviously, you never heard of data center on fire that wipes out all servers or all servers were down for 3 or more days. Just a quick google search and there are so many data centers related issue reported in the past. http://www.thetechherald.com/article.php/200823/1124/The-Planet-Outage-%E2%80%93-H1-Datacenter-suffers-fire-and-explosion-Update-1 http://www.techflash.com/seattle/2009/07/Why_the_Seattle_data_center_fire_caught_companies_unprepared49978502.html http://www.datacenterknowledge.com/archives/2008/03/31/fire-destroys-wisconsin-data-center/ http://www.intology.com/computers-internet/us-data-center-catches-fire-9000-servers-down/ http://www.prisontalk.com/forums/showthread.php?t=340505 anyway, thanks for your other suggestions. Peter
RE: postfix clustering
> > Interesting. This is a _huge_ leap in capability > for any IMAP server > > I'm aware of. Yet, entering either "replication" > or "cluster" in the > > Cyrus home page search box returns zero results. > When will these > > features be released as production ready? Right > now it appears they > > are > > vaporware. > > It sounds interesting, however from a system administrator > point of view it > shouldn't be really difficult to create with the current > tools. With some > custom scripts I think it should be possible to do it with > current tools, > the most difficult part is messages that get deleted from > the file system > (pop3/imap) I guess. > > I can set it up later this year in a test environment and > publish my > findings about it. If this is interesting for others to > know please mention > it and I'll test it and publish it. it is great if you can create a blog to share. Thanks, Peter
Re: Upgrading Postfix and invalid/obseleted config values.
On 19/03/11 09:49, Simon Brereton wrote: From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Daniel Bromberg Just being a googlebot again, but does this help? http://www.courier-mta.org/imap/README.maildirquota.html Using the Maildir++ extended Maildir format: http://en.wikipedia.org/wiki/Maildir#Maildir.2B.2B All thoughts are appreciated. I'll investigate further, but I think my original issue was this warning (without wanting to drag Courier into the Postfix list).. If you would like to have a quota on your maildir mailboxes, the best solution is to always use filesystem-based quotas: per-user usage quotas that is enforced by the operating system. This is the best solution when the default Maildir is located in each account's home directory. This solution will NOT work if Maildirs are stored elsewhere, or if you have a large virtual domain setup where a single userid is used to hold many individual Maildirs, one for each virtual user. I have a virtual domain set up and one UID for delivering mail. I suppose this might be hacked to work but would require more skill than I have. Since I assume Postfix won't respect the quota extension the issue remains a) how to get the MTA to stop delivering mail to the maildir and b) how to warn the user that they are close to over quota and will lose mail. (It may make the blood of some on this list run cold, but I would never configure a Postfix installation of mine to send DNSs back to the sender telling them their precious mail could not be delivered). At best it would have to be silently dropped as it would have already gone through the content-filter (amavisd) and therefore envelope-sender could no longer be trusted. Now, if the quota could be checked (perhaps when doing the mysql lookup on valide users) before the sending agent disconnects - that would be truly marvellous. I think you misunderstand that warning. My read on it is that it is telling you that disk based quotas are better than Maildir quotas, but there are cases where disk based quotas won't work (such as yours). In your case use Maildir quotas which should work fine and which are explained beyond that paragraph. Peter (new to posting here, but have been following the list for a while now).
Suggestion for docs
The SASL_README doc has a section about doing a telnet test of a PLAIN SASL authentication. There are some methods suggested for generating the base64 hash required to do the authentication, Of those two methods one requires downloading a special utility to generate the auth string and the other requires installing a perl module. I have a third suggestion: echo -ne '\000username\000password' | openssl base64 This method is relatively easy to do, and will work with the programs that are already readily available on most systems. I think it would be good to add it to the docs. Regards, Peter Ajamian
Confusing part of Docs
from postconf(5) for smtpd_tls_security_level=encrypt: > Mandatory TLS encryption: announce STARTTLS support to SMTP > clients, and require that clients use TLS encryption. According to > RFC 2487 this MUST NOT be applied in case of a publicly-referenced > SMTP server. Instead, this option should be used only on dedicated > servers. Most of this is very clear, but the term "dedicated servers" in the last sentence is very confusing, in fact I'm left wondering what having a dedicated server has to to with TLS at all. Can you clarify this last sentence and possibly find a better term for the documentation? Peter
Re: Confusing part of Docs
On 14/10/11 15:51, Stan Hoeppner wrote: > On the public internet you can't force remote SMTP servers to use > encryption when connecting to your server, because very few, if any, > public SMTP servers implement outbound encryption in this way. Most > send in plain text, and always have. For instance, what I'm typing > right now will arrive at the Postfix list server. My Postfix smtp > server doesn't support transmitting outbound mail with encryption (yours > probably doesn't either). If the list server did require encryption I > wouldn't be able to send my reply. This is what RFC 2487 is getting at > here. Right, I get this part, it's just the last sentence that is confusing to me. > What "dedicated servers" means in this context are SMTPD servers within > an organization dedicated to a specific task, in this case almost always > relay submission. These are the SMTPD servers that accept relay mail > from your users' MUAs, such as Thunderbird and Outlook Express. Such > clients all support outbound encryption. If you've ever used an ISP > mail account and setup your "outbound SMTP server settings" then you > should understand encryption in this context. > > Configuring the 'submission' service or '587' service in your Postfix > master.cf would create the "dedicated server" mentioned above. Right, that makes sense, but seems to clash with the conventional definition for "dedicated server" (from wikipedia): > A dedicated hosting service, dedicated server, or managed hosting > service is a type of Internet hosting in which the client leases an > entire server not shared with anyone. This is what I (and I think most people) understand "dedicated server" to mean. There must be a better term for this that is less confusing. Peter
Re: Confusing part of Docs
On 14/10/11 19:58, Stan Hoeppner wrote: > This is a result of your limited background and education Peter. The > term "server" was used to describe a software program's role long before > hardware companies adopted the word "server" to describe a class of > machines. You don't know me or my background so please do not make assumptions. I know what server means in both contexts. I also know the generally accepted meaning of "dedicated server"... ...and when someone comes into the #postfix IRC channel (like they did earlier today) seeking help because they read that last sentence in the docs and thought, "I have a dedicated server, I should set that to 'enforce'." and I looked at that section of the docs and thought, "yes, that sentence is confusing", then it should be changed to be clarified or removed altogether (I don't actually think it will detract from those docs to remove it, but it will certainly avoid this confusion). ...or is it your contention that the docs should only be clear to people who were around in the 60's when the term "dedicated server" had a different meaning? Peter
Re: Down To One Problem?
On 24/10/11 06:13, Jack Fredrikson wrote: > I may be dreaming, but this could be my last problem with my > installation. After following all your good advice, I still have this > one problem and it is pervasive in all emails: > > Oct 23 09:50:58 myserver postfix/pipe[30578]: BB2BB5790262: > to=, relay=dovecot, delay=12684, delays=12683/0.18/0/0.27, > dsn=4.3.0, status=deferred (temporary failure. Command output: doveconf: Re-read rob0's last response to you, he told you what is causing this. Peter
Re: Send periodic announcement to our customers
On 28/10/11 00:42, nima chavooshi wrote: > Hi > In our company we want to send periodic announcement or newsletter mail > to our customers (approximate 5 e-mail). because most of our > customers have email account on yahoo and google and AOL mail services, > I concern about that these mail services detect our emails as spam! > Is there any recommendation for send bulk mail ? All of the above mentioned services have guidelines for you to follow when sending bulk email to their customers: http://help.yahoo.com/l/us/yahoo/mail/postmaster/basics/postmaster-15.html;_ylt=ArJo0u8FD0MevRjWn4Dha.cIJHdG https://mail.google.com/support/bin/answer.py?answer=81126&topic=12838 http://postmaster.info.aol.com/Postmaster.Guidelines.php Peter
Re: postfix-pgsql on centos6
You can rebuild the .src.rpm file from CentOS 6 easily for pgsql. You just need the following lines in your .rpmmacros file when you rebuild: %MYSQL 0 %PGSQL 1 Peter On 08/12/11 14:40, Kwasi Gyasi - Agyei wrote: > Hi, > > Any one knows how I can get postfix-pgsql on centos6 without building > from source? centos-plus repository doesn't seem to have rpm e.t.c. >
Re: postfix-pgsql on centos6
On 08/12/11 15:28, Kwasi Gyasi - Agyei wrote: > Thanks, where can I get src.rpm for v2.6.6, the highest version from > here http://postfix.wl0.org/en/available-packages/ is 2.5. ...picking a CentOS mirror at random: http://mirrors.usc.edu/pub/linux/distributions/centos/6/os/SRPMS/Packages/postfix-2.6.6-2.el6.src.rpm
Re: Switching to 587 submission
On 09/12/11 13:11, Grant wrote: > Got it. I misunderstood you before. May I ask why using 465 for > Thunderbird and Squirrelmail would be better than 587 for Thunderbird > and 25 for Squirrelmail talking to localhost? I'm quite sure that he never said to use 465 for Thunderbird. The reason you don't want to use port 25 for submission is because it doesn't work ideally for submission. Port 25 generally needs to have much more strict anti-spam, anti-virus, etc measures on it than you would take with submission. This becomes very clear if you want to start using postscreen which can completely screw up submission when doing the post-greeting tests, or if you are greylisting. Certainly there are many other reasons as well. Peter
Re: postfix devnull mailbox
On 21/12/11 10:11, Dennis Carr wrote:
> In all seriousness, I guess it depends on who you ask. For the original
> poster's case, it's going to a "noreply" address, and I've seen cases
> where nore...@foo.bar is simply eaten, more often than not, rather than
> rejected. Besides, as far as I'm concerned, it does serve as an extra
> use: messages to noreply or similar black hole addresses can serve as a
> receptacle for flames. Some yutz can decide he's going to e a jerk and
> flame somebody that doesn't actually exist - s/he feels good about
> {him,her}self in theory,
...which is exactly why you should never drop email like that. You are
advocating for tricking a sender into thinking that his email was
received when it was not. The number of times of your scenario is going
to be far outweighed by the number of emails that contain important
information. Even in your case it is likely that the ranting sender
wants to be removed from your mailing list and to make him think you've
received this email but not removed him from the list turns you into a
spammer.
There is very rarely a good reason to drop email.
Peter
Re: postfix devnull mailbox
On 21/12/11 13:21, Reindl Harald wrote: > so why does he not use the reply-button and what is he thinking does > "nore...@mail.tld" mean? if you do not read the noreply-address it > is the same as drop the messages, the only difference is on the storage I am not excusing the sender's actions, I am simply stating that if you are going to accept an email for delivery then you should deliver it, to do otherwise gives a false impression to the sender. Peter
Re: postfix devnull mailbox
On 21/12/11 16:01, Stan Hoeppner wrote: > The act of delivery to a mailbox does not guarantee the message will be > read by a human, nor replied to, ever. Thus there is zero practical > difference, from the sender's POV, in this case, between delivering to > /dev/null and to a mailbox whose contents are never read, but deleted > each night via a cron job. As someone else stated, the only difference > is disk space usage. Note that I never said that the only solution is to deliver the email. What I said was that if the email is accepted for delivery it should be delivered. In this case the email should be rejected. > To further shoot your argument down, many postqueue Spamassassin > implementations at the MDA level discard spam before final delivery > millions of times a day around the world. Using your definitions, doing > this is illegal/wrong as well. Yes, this is wrong, just because a lot of people configure SA to drop email does not make the practice correct. There is one case where I will drop email and that is if it contains a virus. In the case of SPAM the best solution is to deliver the email to the user's SPAM folder (that is if it didn't get rejected by postscreen already). > Yes, in a perfect world it's best to reject any mail at smtpd which you > know you will not deliver. But we don't live in a perfect world. Thus, > now and then, 'imperfect' solutions must be used for certain > classes/types of problems. Yes in a perfect world everyone would follow RFCs and do the right thing with email. Just because the world is not perfect is not an excuse for you to make it worse. Peter
Re: postfix devnull mailbox
On 21/12/11 15:19, Reindl Harald wrote: > > > Am 21.12.2011 01:29, schrieb Peter: >> On 21/12/11 13:21, Reindl Harald wrote: >>> so why does he not use the reply-button and what is he thinking does >>> "nore...@mail.tld" mean? if you do not read the noreply-address it >>> is the same as drop the messages, the only difference is on the storage >> >> I am not excusing the sender's actions, I am simply stating that if you >> are going to accept an email for delivery then you should deliver it, to >> do otherwise gives a false impression to the sender. > > but this is not solveable in any way > > if you reject mails to "nore...@yourdomain.com" you will fail > sender-verify everywhere You can reject emails but still allow the address to pass the VRFY command, or better yet, just disable the VRFY command all-together which has other benefits. Peter
Re: postfix devnull mailbox
On 22/12/11 04:56, Stan Hoeppner wrote: > On 12/20/2011 9:19 PM, Peter wrote: > >> In the case of SPAM the best solution is to deliver the email to >> the user's SPAM folder > > You must have an unlimited SAN hardware budget for your 1,000,000 > mailbox site, if you practice what you preach above. No, of course not, but I know how to deal with disk space limitations. > Potential FPs > should be routed to a "spam" folder, if you like. Everything else > should be rejected Yes. > or discarded. There is nothing more frustrating than trying to figure out why your emails are not going through to your customers than when they are accepted for delivery and *not* delivered. I have very little patience for anyone who insists on doing this. > The world is shades of grey Peter, not black and white. SMTP RFCs even > have grey areas Peter. I believe they are worded as "may" instead of > "should". Yes, and the world is full of email admins who don't know what they're doing, what was your point again? Peter
Re: postfix devnull mailbox
On 22/12/11 05:07, Reindl Harald wrote: > On 21.12.2011 15:56, Viktor Dukhovni wrote: >> The real solution is not misuse the "nore...@example.com" *header* >> address as an envelope sender address. >> >> The envelope sender, especially for no-reply automatically generated >> email, must be a valid mailbox that is capable of receiving and >> acting on non-delivery reports (bounces). > > have fun getting blacklisted by bounce mails to the noreply-address > which are spam using a spoofed sender of an existent person! Huh? You're talking about backscatter, which makes no sense here. Viktor was talking about being able to *receive* bounces, not about sending them. Peter
Re: postfix devnull mailbox
On 22/12/11 09:58, Jeroen Geilman wrote: > In postfix' case, "address verification" does not mean "use the SMTP > VRFY command". > It means "send a specially-crafted, actual email message and record > whether the recipient is accepted or not." > > It is documented in detail here: > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > > This will fail if, as previously mentioned, your MTA rejects a recipient > address that was previously allowed to send mail. Only if you reject the email at the RCPT TO stage. See rob0's post for a way to avoid this. Peter
Re: postfix devnull mailbox
On 23/12/11 01:53, Stan Hoeppner wrote: > On 12/21/2011 5:30 PM, Peter wrote: >> There is nothing more frustrating than trying to figure out why your >> emails are not going through to your customers than when they are >> accepted for delivery and *not* delivered. I have very little patience >> for anyone who insists on doing this. > > That's because you're confusing discarding spam with discarding legit > mail. No. > Maybe your spam filters or your own special A/S sauce simply suck? There is no such thing as a 100% accurate SPAM filter. > The LKML list manager, and many others across the globe, treat 5xx > rejections of their list mail as bounces, and unsub members after a > given threshold, 3 IIRC in the case of LKML lists (of which there are > many dozen, 4 which I sub). As they should, they risk being flagged as spammers themselves if they continue to try to deliver to email address that have bounced or rejected. > I was told I must simply eat the spam along > with the rest, or not participate. Yes, this is a stupid draconian > policy, but I must live by their rules, or not participate. You won't actually be rejecting emails from these (unless your MTA is mis-configured) because they are all coming from a legitimate sender. The best you can hope for is to mark them as SPAM based on the content in which case they should be delivered to a Spam folder (which would not trigger an unsub). > Thus, I DISCARD most of the spam from such lists instead of eating it, > then manually deleting it, or sorting it to a spam folder and then > deleting it as you apparently do. Why do all the extra work when a > DISCARD does it for me with zero fuss? Again, see false positives. They do happen, no matter how good your filters are. > This is why I said the world is shades of grey Peter. Yes, and some emails may look like spam to your filters but actually aren't. When you take the draconian solution of discarding everything that looks like spam then you run the risk of missing important emails. Oh, and as for the RFCs, have a look at RFC 5321: 4.2.5. Reply Codes after DATA and the Subsequent . When an SMTP server returns a positive completion status (2yz code) after the DATA command is completed with ., it accepts responsibility for: o delivering the message (if the recipient mailbox exists), or o if attempts to deliver the message fail due to transient conditions, retrying delivery some reasonable number of times at intervals as specified in Section 4.5.4. o if attempts to deliver the message fail due to permanent conditions, or if repeated attempts to deliver the message fail due to transient conditions, returning appropriate notification to the sender of the original message (using the address in the SMTP MAIL command). ...which one of the above says it can drop email without delivering it? Peter
Re: Best way to implement autoreply and spamassassin?
On 05/01/12 12:44, Tobey Wheelock wrote: > On Thu, Jan 05, 2012 at 12:28:03AM +0100, Jeroen Geilman wrote: >> On 01/05/2012 12:19 AM, Tobey Wheelock wrote: >>> On Thu, Jan 05, 2012 at 12:14:26AM +0100, Jeroen Geilman wrote: >>>> These are very different functions. >>>> Spam filtering is best achieved when mail is received, such as with >>>> amavisd-new and spamassassin. >>>> >>>> Autoreply is best taken care of by the users' own delivery agent, or >>>> .forward file. >>> >>> These are virtual users who have requested autoreply and I would like to >>> oblige. They use a webmail program which doesn't offer it, and I don't >>> believe .forward will work since they are virtual users. >>> >>> Is it possible to do this in postfix? >> How are these virtual mailboxes handled ? where does the mail go ? >> >> If you're using, for example, dovecot as the virtual MDA, then it is >> trivial to implement using siege. > > > Yes, dovecot, but I'm not currently using it as LDA. Instead, postfix > delivers the mail itself. There are (at least) two options for you: 1. postfixadmin comes with a vacation program that works with virtual users and can work by modifying SQL tables to change aliases for those users. This is compatible with special extensions for squirrlmail and roundcube. This used to be my older solution and works well. 2. As Jeroen mentioned, you can use the Dovecot LDA for delivery and install sieve. This is also compatible with extenstions for both roundcube and squirrlmail. This has the advantage that you get the other features of sieve, such as you can put in default rules to deliver spam to a separate folder, and you can allow your users to set their own sieve rules to do server-side filtering of emails. This is what I do now for new postfix installs and my clients love having the sieve filtering capabilities. Peter
Re: Best way to implement autoreply and spamassassin?
On 06/01/12 03:49, Tobey Wheelock wrote: > On Thu, Jan 05, 2012 at 11:03:44PM +1300, Peter wrote: >> There are (at least) two options for you: >> >> 1. postfixadmin comes with a vacation program that works with virtual >> users and can work by modifying SQL tables to change aliases for those >> users. This is compatible with special extensions for squirrlmail and >> roundcube. This used to be my older solution and works well. > > Would postfixadmin's vacation program require using postfixadmin itself? No, it comes packaged with postfixadmin but can be installed and used separately. Of course postfixadmin can interface to it and make changes to the vacation settings but this is not required. >> 2. As Jeroen mentioned, you can use the Dovecot LDA for delivery and >> install sieve. This is also compatible with extenstions for both >> roundcube and squirrlmail. This has the advantage that you get the >> other features of sieve, such as you can put in default rules to deliver >> spam to a separate folder, and you can allow your users to set their own >> sieve rules to do server-side filtering of emails. This is what I do >> now for new postfix installs and my clients love having the sieve >> filtering capabilities. > > You mention that you do this for new installs. How hard is it to > convert an existing installation to using Dovecot LDA? Not hard, others have answered this in more detail so I won't repeat them here. Peter
Re: Ok. I'm finding a small issue on my server.
On 08/01/12 20:00, Bjørn Ruberg wrote: > On 01/08/2012 03:26 AM, Benny Pedersen wrote: >> On Tue, 27 Dec 2011 08:22:47 +0100, Bjørn Ruberg wrote: >>> Be advised that if you plan to reject >>> *sender addresses* claiming to originate from your own domain, you >>> might break legitimate mails. >> >> how ? > > Mailing lists like this one, for instance. When you post to the > postfix-users list, your message is redistributed from the list's > servers having your address as the originating address. The message will > originate from outside of your systems but will have your From: address. > If you block this, you won't see your own postings to the list. > > This is an excerpt from the headers in your e-mail: > > From: Benny Pedersen > To: > Subject: Re: Ok. I'm finding a small issue on my server. This is a common misconception. The envelope sender is not the same as the From: header. This is the envelope sender for your message (and indeed for every message from this mailing list): Return-Path: Peter
Re: Disable sending mails via telnet
On 11/01/12 14:57, Reindl Harald wrote: > problem of the OP solved > that he can no longer act as MX properly is another story ...and the fact that openssh s_client gets around that block makes your answer completely useless, even though it may be "technically correct". The correct answer is that you cannot block telnet access to port 25 without also blocking incoming emails from other MTAs, and so you should not try. Peter
Re:
On 28/01/12 00:00, nick wrote: > Il 27/01/2012 11.47, Nickalf ha scritto: >> Hi Fellow Postfixers, ( belated H a P p Y N e W Y e A r ) >> >> Looking to find out the pros and cons of >> using MySQL based Postfix over the current basic (text based) >> setup I have. Is it more secure? must be faster - no? >> >>Thanks, >> Nick. . . > A few things I've noticed.. > > 1. Nowhere near as many reloads needed, you can add domains, change what > they are (local, transport, etc), add and remove users, all from a > browser, instead of from the command line. You don't need to postmap, or > postfix reload very often at all. > > 2. Speedwise, I think it's about the same, in theory reading from text > files is quicker, but mysql is very quick with selects, and I've never > noticed any difference. Being able to pass a question to mysql (does > user d...@email.com exist here) might be faster than looking through a > big list in memory (or a text file), but I think Wietse would be able to > say with much more confidence. > > 3. Makes backups easier, mysqldump occasionally, it's a lot easier than > dealing with PAM and shadow files (if your users are local). > > 4. It's easy to administer users, password, vacations, and a lot of it > can be delegated to the users themselves.. > > I'm sure there are other reasons, but this is my experience. 5. Ability to work with the same data in different ways. You can write different SQL queries for the same data in an SQL table that can do different things, for example you can have a list of IP addresses in the SQL table and in one query you can return PERMIT if there's a match and in another REJECT. In a third query you can return some data that is in a 2nd column of the same table. With flat files you are limited to one match and one return value, and if you want to use the same data for some other purpose you need to copy it to another file. Don't think that you are limited to just using mysql either, a lot of people prefer postgresql and you may find if you take the time to check it out that you do as well, there is also sqlite if you want something lighter weight. Peter
Re: alias and forward
On 28/01/12 13:36, Alessandro Vicari wrote: > I mean that creating an alias my user cannot use these credentials for > authentication on smtp-auth. You need ton configure your SASL AUTH server (dovecot?) to recognize the names in your alias table as well as those in the mailboxes table. How you do this is dependent on the particular SASL AUTH server you use and a question that should probably be directed to their docs and support. Peter
Re: alias and forward
On 29/01/12 06:50, Alessandro Vicari wrote: > Thanks Peter for the explanaition and for pointing me to the right > direction to look at. > I tried it and it works great. Now the thing is to make postfixadmin be > able to create these aliases (which is not because so far as I saw it > checks if the alias already exists and by default it creates a new alias > with the same name of every new mailbox created). > If anyone will be interested, I'll try to send a patch for this in the > ML, unless I'll find a patch already avaliable. Postfixadmin is not part of postfix. No patch is needed, there is an option for postfixadmin to enable editing of those aliases. Peter
Re: difference between /usr/sbin/sendmail.sendmail and /usr/sbin/sendmail.postfix ?
On 02/02/12 16:51, Ctdi Unix wrote: > So here finally the symptoms of my problem! If I send email from the > command line on ServerB, the email ends up deferred. > > remember pickup is commented out in master.cf The sendmail binary that comes with postfix uses the pickup service, it won't work without pickup. Peter
Re: difference between /usr/sbin/sendmail.sendmail and /usr/sbin/sendmail.postfix ?
On 02/02/12 16:51, Ctdi Unix wrote: > And yes I did try and put pickup back, but then I have some sort of > mail loop. I think tied to my custom content filter and it's > configuration. Missed that bit ... You need to debug and fix your mail loop, then. See: http://www.postfix.org/DEBUG_README.html#mail Peter
Re: How to know if my Postfix supports MySQL and PostgreSQL?
On 04/02/12 00:50, Andre Lopes wrote: > Thanks for all reply's. I will use MySQL. CentOS6 don´t have any > usable RPM to PostgreSQL and many users out there had troubles > recompiling Postfix with pgsql support. If you rebuild the RPM with these lines in your .rpmmacros file you will have both postgresql and mysql support: %MYSQL 1 %PGSQL 1 Peter
Re: Adding envelope-from in Received headers
On 13/02/12 20:59, Nikolaos Milas wrote: > Hello, > > I've noticed that message Received headers do not include the > envelope-from address. > > Is there a way to include the envelope-from address in message Received > headers? It's the Return-Path header. Peter
Re: Adding envelope-from in Received headers
On 13/02/12 22:20, Wolfgang Zeikat wrote: > In an older episode, on 2012-02-13 09:24, Peter wrote: > >>> Is there a way to include the envelope-from address in message Received >>> headers? >> >> It's the Return-Path header. > > AFAIK, Return-Path is not part of the message header during SMTP > transport, but it is added by the MDA (mail delivery agent) during > delivery. Correct, however the result is that the Return-Path contains the envelope sender nonetheless. > To add the envelope-from address to the mail header, we use: > > In main.cf: > smtpd_data_restrictions = check_sender_access > regexp:/etc/postfix/regexp.sender_data > > In /etc/postfix/regexp.sender_data: > /(.*)/ prepend X-Envelope-From: <$1> Sure, if Return-Path isn't good enough then this certainly works. Peter
SASL_README needs updating for dovecot 2.0 config
The dovecot config listed in the SASL_README is obsoleted for dovecot
2.0, it should probably be updated to reflect that. I'm not sure
exactly what should go in the SASL_README file but I'll show the
relevant part of my own dovecot config (which uses an sql db for
authentication, not pam):
auth_mechanisms = plain login
passdb {
args = /etc/dovecot/sql.conf
driver = sql
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
unix_listener auth-userdb {
group = dovecot
mode = 0660
}
}
userdb {
args = /etc/dovecot/sql.conf
driver = sql
}
Note that if you put the old config in dovecot will give a warning on
startup and `doveconf -n' will show the new config that you should
replace it with.
Peter
Re: SASL_README needs updating for dovecot 2.0 config
On 20/02/12 11:14, Wietse Venema wrote:
> Peter:
>> Note that if you put the old config in dovecot will give a warning on
>> startup and `doveconf -n' will show the new config that you should
>> replace it with.
>
> http://www.postfix.org/SASL_README.html was updated for Postfix 2.9.
> What are the errors?
This is what I get when I use the settings shown in the latest
SASL_README doc (as per the link you posted above)
Warning: NOTE: You can get a new clean config file with: doveconf -n >
dovecot-new.conf
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:14: add
auth_ prefix to all settings inside auth {} and remove the auth {}
section completely
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:16:
passdb pam {} has been replaced by passdb { driver=pam }
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:18:
userdb passwd {} has been replaced by userdb { driver=passwd }
if I run doveconf -n to get a clean config I get the following config
(parts not related to SASL removed):
auth_mechanisms = plain login
passdb {
driver = pam
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
userdb {
driver = passwd
}
When I replace the recommended SASL config settings from SASL_README
with the above then dovecot starts without complaint.
Note that the above is for dovecot 2, I am unsure as to whether dovecot
1 will run with the changed settings or not, at a guess it won't. This
may leave you in the unenviable position of having to expand the
SASL_README doc to account for two different major versions of dovecot.
Peter
Re: Forward only email for certain domains
On 21/02/12 09:10, Jeroen Geilman wrote: > On 02/20/2012 03:45 PM, /dev/rob0 wrote: >> When starting a new thread, please do not reply to an existing one; >> make it a new message. This one contains irrelevant threading >> information in the headers, which causes a problem for thread-aware >> mail readers. Thanks. >> > > I'm curious which these are - I have no problems with his message on > Thunderbird 3.1.16. In Thunderbird go to "View" / "Sort by" and select "Threaded" and you will see it. Peter
Re: using postgres functions for domain tables
On 23/02/12 05:30, Matthias Leopold wrote: > how do i make a postgres plperl function return a value/row only when > certain conditions are met and otherwise return "nothing"/void/0 rows? > right now my function returns "1 row" even when i return undef. Have you tried using your function in the WHERE clause of your SQL query? Peter
Re: using postgres functions for domain tables
On 23/02/12 23:32, Matthias Leopold wrote:
> could you give me an example of how to do this?
> right now i'm calling my function like
>
> select function('foo');
> or
> select * from function('foo');
Give more details about what this function does and what output you
expect from it.
Peter
Re: Postfix as smarthost for local netwok
On 28/03/12 07:59, Pierre-Gilles RAYNAUD wrote: > 450 4.1.8 : Sender address rejected: Domain not > found; > > smtpd_sender_restrictions = check_sender_access > hash:/etc/postfix/sender-checks, reject_unknown_sender_domain, > reject_non_fqdn_sender, Your emails are getting rejected by the reject_unknown_sender_domain restriction above due to the domain serv002.domain.com returning NXDOMAIN for a DNS query of A and MX records (see postconf(5)). Peter
Re: remark on postscreen behavior in case of big MTA pool - CIDR list needed
On 30/03/12 21:02, Maciej Uhlig wrote: > So, google.com got 450 from postscreen and repeated delivery from > _other_ IP and then got another 450. It's possible the mail would not be > delivered at all if google.com had sent it from different 60 thousands > :-) IP addresses every time. > > The cure could be DNS whitelisting but we know it's not applicable in > postscreen's permanent whitelist. We added then IP subnet 74.125.0.0/16 > to permanent whitelist. But we know there are other ISPs who could send > mail in a similar way. I've only seen this issue from google. You can get a list of possible IPs for them by checking their SPF record, after adding all the networks from their SPF record I stopped having this issue. Peter
Re: Want to Install Postfix but Afraid of Breaking MySQL
On 02/04/12 06:17, Viktor Dukhovni wrote: > On Sun, Apr 01, 2012 at 03:38:34PM +, Robinson, Eric wrote: > >> We only want to install postfix as a null client for sending >> alerts from our servers. When I try to install postfix, it wants >> to install mysql-libs-5.1.61-1.el6_2.1 as well. I'm afraid this >> will break our mysql servers, which are all running MySQL 5.0.77. >> Will installing postfix break things? If so, is there a way to >> install postfix without MySQL support? I don't mind building postfix >> from source if necessary, but I would prefer to install via RPM. > > Install Postfix without MySQL, the Postfix sources from postfix.org > by default build without mysql support. On Debian systems, the > MySQL map support is a separate optional module in the packaged > Postfix. > > On RPM-based systems, you just need to tweak the spec file in > the SRPM to *not* enable MySQL support. So obtain the SRPM > that corresponds to your system's Postfix install and build > it without MySQL. You don't even need to do that, you just need to add a line to your .rpmmacros file: %MYSQL 0 > Note that Postfix does not install a MySQL server, it just depends > on client libraries, which are often dependencies of other packages > on your system (say Perl modules that support MySQL, ...). It is > likely that your MySQL data server is installed elsewhere, and is > not going to conflict with the client library package. Of course > test this on a non-production system, don't take my word for it. Fully off-topic advice: To be safe from any program trying to install mysql (or the possibility that a yum update might try to upgrade mysql) you should exclude mysql* from the base and updates repos in yum. Peter
Re: TLS SNI support?
On 07/05/12 14:21, Fiona Hines wrote: > How do I get TLS SNI support in Postfix? I can't find any documentation > on the subject except a few discussions that are several years old. > I've got TLS working with one domain but I want to expand it to an > unknown number of domains and I don't care if the mail client lacks > support for SNI. You don't need SNI support for multiple domains, you simply need to have your common name (CN) in the certificate match the 250 response of your server. If SNI was required then services like google apps would be in trouble. Peter
Re: TLS SNI support?
On 07/05/12 18:46, Fiona Hines wrote: > That won't work for me. SNI support is the only solution for my > scenario sinceI can't use just one SSL certificate. I haven't used > Google Apps to know what you are talking about. I used google apps as an example of a provider that services what probably amounts to tens or hundreds of thousands of domains for email, and they do it all with one SSL certificate with only a single common name. smtp is not http and it does not work the same, you simply do not need to have a separate SSL certificate for every domain you host, one certificate will work for everything. > And I've got a feeling that the "250 response" part of your reply is > just wrong - which 250 response? Certificates are validated by clients > during the handshake and the connection is terminated if the > verification step fails. That happens long before even the SMTP banner > is emitted. I meant 220 greeting which happens before the STARTTLS command that initiates the TLS handshaking. There is also a 250 (plain text) response after the initial EHLO or HELO that also occurs before initiation of the TLS handshaking. I think you need to have a good read of: http://www.postfix.org/TLS_README.html Peter
Re: Postfix ignores -o always_bcc and -o recipient_bcc_maps
On 13/05/12 05:04, Владимир Кутявин wrote: > Ok there. Any way to make postfix do bcc for themessages from specified > sender to specified recipient? sender_bcc_maps Peter
Re: Syntax error in main.cf
On 13/05/12 10:17, gabrielt...@gmail.com wrote: > postfix: fatal: /etc/postfix/main.cf, line 30: missing '=' after > attribute name: "This file lists only a subset" WAG: Looks like you're missing a hash mark (#) at the beginning of the line to denote a comment. > queue_directory = /var/spool/postfix That's not the line it's talking about. Peter
Re: Syntax error in main.cf
Please don't top post, it's annoying. On 13/05/12 13:59, gabrielt...@gmail.com wrote: > From: Peter > Date: Sun, 13 May 2012 11:37:31 > > On 13/05/12 10:17, gabrielt...@gmail.com wrote: >> postfix: fatal: /etc/postfix/main.cf, line 30: missing '=' after >> attribute name: "This file lists only a subset" > > WAG: Looks like you're missing a hash mark (#) at the beginning of the > line to denote a comment. > >> queue_directory = /var/spool/postfix > > That's not the line it's talking about. > This is strange, when I go to the line that the error is refering > (with nano +30 /etc/postfix/main.cf) the editor opens right in the > queue_directory line, so I put a # in that line for testing and run > postfix check again, and I then receive an error in the > command_directory line, which is also with the default setting You're not paying attention to what I said. Look for the line with the text, "This file lists only a subset". Your error message specifically references that text as being the problem. Peter
Re: Virtual Users Setup
On 04/06/12 12:55, Schiz0 wrote: > Hello, I've had postfix setup using unix system accounts for a while > now, with ClamAV and Spamassassin. I would like to setup virtual users > now on the system, but I'm having some problems. Mail doesn't seem to > be delivered to my /usr/local/vmail folders. I'm using PostfixAdmin > and populated the proper tables with aliases and user accounts. Here's > a pastebin of my postqueue -p, postconf -n, and my maillog. > > Thank you. > > http://pastebin.ca/2157920 >From your logs: /usr/local/etc/postfix/sql/virtual_alias_maps: Permission denied Check what user proxymaps is running as and make sure it has permission to access that file. Peter
Re: email signing headers .
On 15/07/12 00:53, achal tomar wrote: > actually Viktor this signed by: header requires DKIM authentication so > when mails are sent from many servers on the same domain then their > signatures are different but having the same signed by: header means > that they are authenticated from a single domain and this do not > requires dkim to be set up in all the servers entry in a single server > is enough. You still haven't said what the actual purpose is for you to use dkim. If you just want to be able to verify that the server that is relaying your emails is authorized to do so then SPF is much simpler and easier to set up for this purpose. Peter
Re: postfix apprently uses mboxo format with local(8), which irrecoverably corrupts mail
On 29/10/12 10:14, Christoph Anton Mitterer wrote: > Even if there was some major compatibility issue with mboxrd (which I > don't see yet)... wouldn't data integrity of the user's mail be of the > "highest" priority? > > As said, with mboxo one has basically no chance at all to recover the > original mail, than guessing... with the other formats, one at least can > do so. You know you could just use a different delivery agent that supports the mbox format you want. Nothing says that you have to use local(8). Peter
Re: avoiding overload on port 587
On 04/12/12 20:54, Tomas Macek wrote: > Everyone here says me, that MUAs should send their mails through 587. I > can't do that without iptables, because all the people here have Outlook > Expresses setup with port 25 for sending emails from default configuration. That's the general advice, yes, but the real issue is to keep your submission service separate from your mx service. You can allow submission on port 25 and still have it separate from MX if that submission service is on a different IP address to your MX. As an example, say that your users currently submit to the host mail.example.com, you can change the IP of mail.example.com to point to a new IP (on the same server) and set up postfix so that it runs a submission service on that IP on port 25. You can then point your MX record to a different hostname (mx1.example.com) and point that to a second IP address on the same server, postfix can then be configured so that port 25 requests to that IP are treated as mx requests and not submission. With this setup you get to separate your submission from your mx but still don't have to require your users to make any changes to their clients. I would still also set up port 587 on the mail.example.com IP as submission as well and try to encourage your users (at least the ones you can) to use port 587 from now on. Also, if they don't have authentication set up, then you can use mynetworks to authenticate them, but you may be better off using a check_client_access cidr table instead for better control of this. Peter
Re: Possible bug with recipient_delimiter minus in usernames
On 16/12/12 13:45, decoder wrote: > On 12/16/2012 01:22 AM, Wietse Venema wrote: >> I don't recall that Postfix documentation promises >> this for UNIX system account lookups. > > This one: > > # Basically, the software tries user+foo and .forward+foo before trying > user and .forward. That's from postconf(5) recipient_delimiter, btw, and it does look confusing to me, what is the intended meaning wrt user+foo and user here? Also the log entry says this: > Dec 15 17:59:09 mailhost postfix/local[7486]: B4D124341: > to=, relay=local, delay=0, status=bounced (unknown > user: "foo-test") Wouldn't that be better if it says, '(unknown user: "foo")'? This in consideration that the user foo-test actually does exist in the system, and the reason it couldn't find it is that it was looking for "foo", or is there something I am missing here? Peter
Re: Learning how to respecth REPLY-TO headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/01/13 06:15, Reindl Harald wrote: > i DO want supress duplicates it works on a lower level -> dbmail > > i am receiving around 500 mails per day with duplicates still > supressed so i do not need them too in a different folder to save > two seconds for some of the mails > > buisness-emails ALWAYS MUSTE BE reply-all and have to be so, one > reson more that it sometimes can happen you hit the same for a > list-reply after 50,60,100 business-mails Thunderbird has a great "smart reply" button that works well for the vast majority of cases. It is a button with a drop down that allows you access to all the different reply mechanisms available for the email you're replying to with the "smartest" one shown as teh default for a simply click: If there is a list header there is a "reply to list" option and it is the default. If there are multiple recipients then there is a "reply all" option and barring "reply to list" it is the default. There is always a simple "reply" option and it is the default barring none of the above. Since I found that button I have replaced my simple "reply" button with it on the toolbar and have never had an issue since. Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ8dciAAoJEAUijw0EjkDv6MQH/0gro/qjOLrXyb4WCF9lx9q4 8atSUpImNVxp72ntwQ0sXj2u39U1xy3WoI1ClwiwWE6i8QLSuiO/OO+0wPTtN1Vk v8nWLGSmsGyrYuxda5DwiMco2ei9qOMt8/nGu4hLxvFj54I62K9VLFrPLcQtkz3p LSX6uS3IVqw7Ptwpm9Slgw9pb6nWf9E4ertPk4eRWHo/JWNqwuFuFG7A+3LKWQK0 hqJmUysSsvqCxF4oMPWK6rILVahz6WWQ7ad6wRFS4yJCTAwZkzB04vd0nVWZLpRr EhAHsItAfqpLPmoWZYD3z3Qw8nCyVYWGa7RIPQ3dU81wzOwZv5nFFSUmYjEd2E0= =axtZ -END PGP SIGNATURE-
Re: Forward internal RHEL6 server local user emails to postfix mailrelay
On 03/23/2013 12:35 PM, Michael Maymann wrote: Hi list, I would like to forward all our internal RHEL6 server localuser emails to our postfix mailrelay. I have tried the following already on the RHEL6 servers: - .forward will not allow e.g. root to forward mail to user1 - relayhost only relay mail for external users Is there a global postfix setting for this ? Look at /etc/aliases Peter
Re: reject_unknown_reverse_client_hostname safe?
On 05/08/2013 08:12 AM, Stan Hoeppner wrote: In addition, if FCrDNS was indeed a requirement, then nobody would accept mail from my SOHO Postfix server, nor any mail servers behind the tens of thousands of "business class" ADSL circuits in the US which offer static IPs but not custom rDNS. You yourself accept mail from my outbound, so obviously you're not strictly enforcing FCrDNS. That or you've manually whitelisted my IP. Actually (1) it's the mailing list mx that needs to accept your server, and (2) your IP *does* actually pass fcrdns: greer.hardwarefreak.com. 3448 IN A 65.41.216.221 221.216.41.65.in-addr.arpa. 86176 INPTR mo-65-41-216-221.sta.embarqhsd.net. mo-65-41-216-221.sta.embarqhsd.net. 86166 IN A 65.41.216.221 Peter
Re: reject_unknown_reverse_client_hostname safe?
On 05/08/2013 11:41 AM, Vincent Lefevre wrote: Perhaps for IPv4 (but this depends: some people send mail to a few restricted people). If only the IPv6 address lacks a PTR, this is probably not true, at least in France, where the biggest ISP's don't support IPv6, so that there are no deliverability issues with them. Only with the few people who have a MX with IPv6 support. Nope, I can tell your from experience that Comcast will reject your mail if you relay it from an IPv6 address that doesn't have a PTR. Peter
Re: reject_unknown_reverse_client_hostname safe?
On 05/08/2013 11:02 AM, Vincent Lefevre wrote: I suspect that they temporarily changed the Ethernet card without updating their DNS config, as only the last 6 bytes of the IPv6 address changed for this particular mail. There are lots of ways that IPv6 can get messed up, and people tend not to notice when it happens because relatively few people use IPv6 yet. I can tell you from experience that it's very easy to misconfigure an IPv6 box and end up sending mail out on an IP other than the one intended. I had issues myself recently with my VMs picking up autoconfigured IPv6 addresses and using those instead of the ones that I manually configured. Also it becomes more of an issue with IPv6 because you tend to only configure PTR records for those IPs you actually intend to use (can you imagine how big of a file you'd have if you configured a PTR for every IP in a /64 block?). Anyways, you should expect to have problems with IPv6 from time to time if you're using it now. You can either accept that these sorts of issues will crop up and do the best you can to resolve them and help others resolve them when they do, or disable IPv6 on your production machines and stick with IPv4 until IPv6 adoption has reached a level where it's more stable. Peter
Re: reject_unknown_reverse_client_hostname safe?
On 05/08/2013 08:03 PM, Stan Hoeppner wrote: On 5/7/2013 5:36 PM, /dev/rob0 wrote: ... Peter has explained this: you indeed seem to have FCrDNS, just not Maybe my understanding of the definition of Forward Confirmed reverse DNS is incorrect. I thought the definition of FCrDNS is that that the forward and reverse names not only exist but also match. Apparently they both must simply exist. No, they have to match, I'll go into detail so that hopefully you understand... Your host claims to be greer.hardwarefreak.com and connects from the IP 65.41.216.221, so first we do a lookup on your hostname: greer.hardwarefreak.com. 3448INA65.41.216.221 ...it matches the IP of your connection ... This is good. Next we do a reverse lookup on the IP: 221.216.41.65.in-addr.arpa. 86176 INPTR mo-65-41-216-221.sta.embarqhsd.net. This doesn't return your initial hostname, but that's ok because that is not specifically required for FCRDNS. What is required at this stage is that the PTR lookup return a valid FQDN and it does indeed. Note that the FQDN that is returned "looks" like a generic ISP-assigned hostname (because of the IP address in the name). This isn't a good thing and there are some mail hosts that will reject based on this, but very few in my experience. That generic-looking hostname does not mean that it won't pass FCRDNS, though. Ok, next we do a lookup on the hostname we got back from the previous step: mo-65-41-216-221.sta.embarqhsd.net. 86166 IN A65.41.216.221 ...this returns your IP address as well, and that is good because this is required for FCRDNS. Peter
Re: patch: mitigate CRIME attack
On 05/14/2013 05:05 PM, Viktor Dukhovni wrote: Don't listen to brainless auditors wielding checklists. Unfortunately you have to. They may be wrong but you're not going to pass PCI compliance scans unless you jump through their stupid hoops. I recommend that you don't put your MTA on the same server that you run your ecommerce apps on anyways, then you don't have to worry about passing PCI scans on the MTA. As for this particular issue, I believe you can work around it to the satisfaction of the auditors by disabling any CBC ciphers. You can use the command, "openssl ciphers" for a list, and then set smtpd_tls_exclude_ciphers to any that have CBC in the name. No need to worry about smtp ciphers as the scanner can't detect those anyways. Peter
Re: Postfix, Autoreply
On 05/21/2013 09:51 AM, Timo Röhling wrote: Have a look at http://www.postfix.org/addon.html#autoreply and pick the solution that is the easiest for you to setup. I have two to add to that list: 1. Virtual Vacation which comes packaged with PostfixAdmin (but does not require PostfixAdmin to use). 2. dovecot sieve and managesieve plugins (probably with other sieve implementations as well). There are addons in both Roundcube and Squirrlmail for both of the above so that users can set their own autoreply messages. Peter
Re: permit ip, reject domain
On 05/31/2013 03:50 AM, Feel Zhou wrote: I don't think that document is good to fix this problem I want sender address match my customer's domain name If not match ,mean that sender address was fake Hi Tom, This is a bad idea, it is very easy for a spammer to spoof your customer's sender domain in order to relay mail through your server and then your server becomes not much better than an open relay. You should look into SASL AUTH, this is a much better way for your customers to authenticate to your server for relaying: http://www.postfix.org/SASL_README.html Peter
Re: permit ip, reject domain
On 05/31/2013 12:34 PM, Noel Jones wrote: No, the client is already authorized by IP. Adding a sender domain check is an additional restriction. This is also a simple "some trusted IP is sending a bunch of crap" trigger. Good advice, but SASL is not always possible or practical. And solving this with SASL involves reject_sender_login_mismatch, which brings its own complications. This is all based on an interpretation of the OPs original broken English posts, though. What I was seeing was something akin to, "I need to prevent spammers from using my server as a relay, so I'm going to stop anyone who doesn't have an authorized domain in the envelope sender." You probably noticed something I didn't in his posts, though. Peter
Re: Is it time for 2.x.y -> x.y?
On 06/01/2013 08:56 AM, Wietse Venema wrote: After the confusion that Postfix 2.10 is not Postfix 2.1, maybe it is time to change the release numbering scheme. I would take the confusion with a grain of salt, and I think that changing the numbering scheme will generate even more confusion. I tend to agree that the major number should only be incremented with a major code cleanup / backwards compatibility change, etc, but the thing is that postfix doesn't seem to need one and I personally can't foresee such a major change anytime in the near future because postfix is very well maintained already, so this tends to translate into "we're going to have 2 forever", which is not such a good thing, imo. It gets more confusing when we get to versions such as 2.26, and later on down the road 2.56, and so it becomes harder to separate one version from the next. So what I would suggest instead is to relax the standard for a major version change a bit so that a major new feature would also be cause for a major version change. Such an opportunity was recently missed with the introduction of postscreen in version 2.8. Peter
Re: Challenges of an internal relay server
On 06/01/2013 08:53 AM, Jason Price wrote: #smtpd_recipient_restrictions = permit_mynetworks, # reject_unauth_pipelining, # reject_non_fqdn_recipient, # reject_unknown_recipient_domain, # check_recipient_access = hash:/etc/postfix/recipient_access, # permit That's wrong becuase (1) you are not doing further filtering for anything that is in mynetworks and (2) if it weren't for postfix requiring some form of reject at the end anything that is not in mynetworks gets a free pass (open relay) unless it is rejected by one of the other filters. What you want instead is to move permit_mynetworks to the end of the list and follow it by reject: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, check_recipient_access = hash:/etc/postfix/recipient_access, permit_mynetworks, reject Peter
Re: Challenges of an internal relay server
On 06/03/2013 12:44 PM, Peter wrote: What you want instead is to move permit_mynetworks to the end of the list and follow it by reject: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, check_recipient_access = hash:/etc/postfix/recipient_access, permit_mynetworks, reject One thing I should note here. If you do the above make certain that none of the entries in /etc/postfix/recipient_access return OK (or 2xx), if they do then any message to that recipient will bypass permit_mynetworks and be accepted regardless of the source. If you are running postfix >= 2.10 then a safer way would be to do: smtpd_recipient_restrictions = permit_mynetworks, reject smtpd_relay_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, check_recipient_access = hash:/etc/postfix/recipient_access ...then if the client is not in mynetworks it will be rejected regardless of what any other restrictions return. Peter
Re: STARTTLS not announced?!
I do realize that this thread probably shouldn't be continued, however I see some gross miss-statements here that need correcting so that someone browsing the thread won't be mislead by them at a later time... On 06/16/2013 01:58 AM, Benny Pedersen wrote: smtpd_tls_auth_only (default: no) "When TLS encryption is optional in the Postfix SMTP server, do not announce or accept SASL authentication over unencrypted connections. " it does not say it disables auth anywhere, it just says it would not be possible to connect without starttls or not, No it disabled auth until STARTTLS is established. It has nothing to do with the connection. just becurse it seldom seen in real life that no one will send auth over an non tls/ssl does not mean it does not work It does not work if smtpd_tls_auth_only is set to yes. starttls is just for clients to use ssl/tls on port 25, Actually clients shouldn't use port 25, and neither should you be using auth on port 25. Clients will use STARTTLS on port 587, however, and both postfix and MUAs can be configured to use STARTTLS on any port you wish (via master.cf). email clients will not use starttls in 2013, Seriously? So how is an MUA intended to establish an encrypted connection to an MSA, then? since submission is the right thing anyway Submission is a port (587) which uses the (e)smtp protocol to submit messages from an MUA (email client) to an MSA (email submission server) and can use STARTTLS for encryption. There is no other way to do encryption on the submission port. it still not needed to use ssl/tls to make auth work It is if you set smtpd_tls_auth_only=yes. Peter
Re: Send email for users from any location
On 07/09/2013 05:10 AM, Dotan Cohen wrote: on a related note, as this is for humans to send mail from their mail clients, you'll want to configure a proper submission [port 587] service. see the commented example in master.cf for a starting point. smtp auth should be offered only via the submission service, and not via mx service [port 25]. additionally, encryption should be required for submission traffic. Are you referring to this: #smtps inet n - - - - smtpd # -o syslog_name=postfix/smtps # -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 No, the service you're looking for is "submission", not "smtps". SMTPS is a deprecated means of submission and you only need it if your users are using a very old version of one particular email client in which case they likely have other problems. Peter
Re: Send email for users from any location
On 07/09/2013 05:13 PM, Dotan Cohen wrote: 212.179.241.14 is the address where my desktop is located, and bzq-* obviously by the name refers to my ISP (Bezeq). It seems that even with submission enabled, Postfix wants the IP address whitelisted in "mydomains". I don't even see in the logs that Postfix bothered checking the submission credentials, it rejected bases on IP address before even getting that far. This simply means that either your email client is not correctly configured to send SASL AUTH credentials, or postfix is not correctly configured to receive them. There is more to SASL AUTH than just enabling submission. See http://www.postfix.org/SASL_README.html for more info. What else must be configured to remove the IP address whitelist and go right to the submission credentials check? You can remove permit_mynetworks if you want, there is nothing wrong with this, but it won't solve your problem, your problem is what I stated above. http://www.postfix.org/VIRTUAL_README.html http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL https://help.ubuntu.com/community/Postfix Read the SASL_README document I linked to above. Peter
Re: How to configure virtual users
On 07/11/2013 02:51 PM, SONNY LASKAR wrote: Please let me know the link of a proper document for configuring virtual users. http://www.postfix.org/VIRTUAL_README.html Peter
Re: Mail server, what else?
On 07/13/2013 11:15 AM, J Gao wrote: http://vault.centos.org/6.4/os/Source/SPackages/postfix-2.6.6-2.2.el6_1.src.rpm And patched with quota patch. That's brilliant, now you can't get support for it anywhere. You don't need to patch postfix to get quotas, dovecot 2 has a policy daemon that plugs right into postfix for that now. Seriously, go to Dovecot and get a newer version of postfix. It is well worth it just to get postscreen support (which requires version 2.8 or higher), and you really don't need to be patching it. Peter
Re: How best to eliminate "domain mismatch" warning in mail clients when TLS is used
On 07/16/2013 05:30 AM, Ben Johnson wrote: If your clients insist that a mail server is only professional if the TLS session has their domain name written on it, then give them what they want at the price it costs to implement it. Your position is perfectly reasonable, and is more or less the position that I've taken on the matter. I just wanted to be sure that there isn't some panacea that I had overlooked. In order to give our clients what they want, what are our choices? Probably the best option is to go old tech here. Get a separate IP for each hostname that a client wants to connect to and set up separate listeners in master.cf for each of those IPs with the appropriate TLS options. Then let the clients buy their own cert and provide it to you to use on the server. Up to you to come up with the additional pricing for all of this. The extra dedicated IP is the first and most obvious cost, the rest is administrative. Keep in mind that you'll have to configure dovecot (or whatever you use for IMAP/POP3) to listen on these other IPs and use those customer-supplied certs as well. Personally I would ramp up the extra fee even more to account for the, "I don't want to do this really stupid unnecessary vain thing" reason. I would make sure the client knows that they are just spending extra money to satisfy their own vanity and if they still want to go ahead then do it for them. Peter
Re: Once more around with dovecot
On 08/16/2013 01:58 AM, /dev/rob0 wrote: > You should still be able to use a Dovecot 1.x configuration > file with 2.x, which will complain in the logs about the changed > syntax and suggest that you use "doveconf -n" to get a proper 2.x > configuration file. I'm going to clarify this a bit. This approach does work for the specific config changes we're discussing in the postfix docs, but it is not always the case. I know from experience that if you take a full dovecot 1.x config file, run doveconf -n on it from dovecot 2 and plug the results directly into dovecot 2.x odds are you will have to make a few additional tweaks to get it to work properly. I have brought up the documentation issue wrt the dovecot 1.x config on this list in the past and it was discussed and nothing changed in the actual docs. I do think that either the example dovecot config needs to be replicated in the docs for dovecot 2.x or it should simply be removed and a reference made to the dovecot docs. Just having the 1.x config is very confusing, imo, especially since the vast majority of people will be on 2.x now. Peter
Re: Server to Server TLS encryption?
On 08/18/2013 07:44 PM, li...@rhsoft.net wrote: > smtp_use_tls= yes Don't use this, it's obsolete and replaced by ... > smtp_tls_security_level = may ... this. Peter
Re: newbie check Was [Re: port 25 submission settings sanity check]
On 08/30/2013 08:53 AM, Terry Gilsenan wrote: > There are no MTAs that accept submission on UDP, yet, so maybe reserved > for future use? No, it's just the assignment from IANA. In the past when either a TCP or UDP port assignment was requested both were assigned, this does not mean that there is or ever was any intention to use the UDP port for the service: http://tools.ietf.org/html/rfc6335#section-7.1 Note that this is no longer the case (as per section 7.2 of the same RFC above). Peter
Re: newbie check Was [Re: port 25 submission settings sanity check]
On 08/30/2013 02:49 PM, John Levine wrote: > >>> submission 587/udp > > I've been doing this for a long time, and I've never seen anyone try > to do SMTP over anything other than TCP. You'll see this for a lot of services in the file. The old practice was for IANA to assign both tcp and udp when a service requested either so seeing udp assigned to a service doesn't mean much if anything. Peter
Re: HELO
On 09/02/2013 12:04 PM, LuKreme wrote: > On 01 Sep 2013, at 15:35 , Noel Jones > wrote: >> If you want your HELO to be consistent regardless of which IP is >> used, use a separate hostname that points to both A records. >> >> mail.example.com A A.A.A.A >> mail.example.com A B.B.B.B > > Won't this cause a problem with the MX records? They will both point > at mail.example.com and one of those IPs will not be available at any > given time. Not if you point them to mailA.example.com and mailB.example.com. Peter
Re: ISP has no reverse DNS for ip address
On 09/02/2013 12:11 PM, Noel Jones wrote: > On 9/1/2013 6:57 PM, Roman Gelfand wrote: >> On every machine, at different locations, I have tried "dig -x ip >> address" and it works correctly. >> >> I have 4 messages stuck in a queue which are complaining about the >> very thing that works. >> >> refused to talk to me: 451 Sender's ISP has no reverse DNS for ip address >> >> Can somebody tell me what is going on? > > It appears the recipient is unable to find your rDNS. You might > check your setup with some external tools, or maybe the recipient's > DNS is broken. > > Or the reason given could be incorrect, and they don't want your > mail for some other reason. If your DNS looks OK, you'll need to > contact their postmaster. A lot of times the complaint is about RDNS when they really mean FCRDNS. Check that forward records match as well before you go off complaining to the other postmaster. Peter
Re: Google rejecting IPv6 mails
On 10/08/2013 11:16 PM, postfix wrote: > Mail from our system wasn't accepted oftentimes by Google either. > I discovered the following solution: Our mail server has got two IPv6 > addresses in the open Internet, one is specific, the other one > automatically created. The first one was in the DNS, the second one not. > I noticed that many times messages where sent using the automatically > generated IPv6 address, which were the mails Google rejected. I've had this issue before. My solution was to turn off ipv6 autoconf in the kernel since I do not want IPs that I do not explicitly assign. > Since I > introduced the automatically generated IPv6 address into the DNS, Google > accepts all mail from our server. To me this is a bad idea, you're working around the issue instead of fixing the real issue which is that you're getting IPs on your server that you didn't configure for. Peter
Re: Domains without MX Records
On 10/13/2013 05:10 PM, Roman Gelfand wrote: > On Sun, Oct 13, 2013 at 12:04 AM, Roman Gelfand wrote: >> >> said: 451 Temporary local problem - please try later (in reply to >> RCPT TO command)) > sorry about this. I guess it has nothing to do with mx records. It > is the remote server telling me their server is not able to accept > mail. Right and the 4xx code explicitly tells postfix to defer the mail and try again later, hence why postfix is (correctly) saving the mail in the deferred queue. It will retry until the delivery is successful or it fails with a 5xx code, or or up to five days (by default). Peter
Re: postfix reports no rDNS on a host with many PTR records
On 10/16/2013 04:03 AM, Blake Hudson wrote: > > Thanks for the reminder about where to locate the test programs Wietse. > I confirmed this appears to be an issue with RHEL5 (all patches applied > today). The issue is resolved in RHEL6. I am running a local instance of > BIND (bind-9.3.6-20.P1.el5_8.6) on the affected server(s). el5 also has bind97 packages, try upgrading to that and see if it fixes your issue. Peter
Re: Postfix still sending bounces
On 11/06/2013 07:01 AM, Vijay Rajah wrote: > > How do I configure postfix to drop the mail rather than reject? Is it > configurable? Why on earth would you want to drop mail that you can reject? > I have already configured my servers to REJECT all mails > not-intended to my domains and non-exsistant users and I do not accept > mails from non-exsistant domains. Is this enough? That's a good start, it also helps to do as much screening pre-queue as possible and to reject mail based on that. postscreen is an excellent tool for this. > What do I do when I accept an email, only to later find out the user's > quota is full? You shouldn't be doing this (see below), but if you must accept the mail then I would highly recommend you deliver it, even if the mailbox is over quota. > (it only recently that dovecot has an way for REJECTING > mail on such cases). Correct, dovecot now provides a policy daemon that works well with postfix, use it and reject that mail as you should. > Do I Bounce that email or drop the mail (After I > have accepted it? Surely, in this scenario the correct thing would be to > BOUNCE is it not?)? Consider that if a user goes over quota and you cannot, due to bad configuration, reject the mail, and you bounce, like you seem to want to do, then all it takes is for a spammer to spam that user with various spoofed senders and you have instant backscatter. > I'm just trying to understand the ways to prevent BOUNCEs.. Prevent bounces by rejecting as much as possible instead. If you're in a situation where you think you have then often times if you think a bit more creatively you can avoid bouncing or dropping mail. In the case of SPAM you can deliver to the user's "Spam" folder, in the case of viruses you can quarantine. I'm not saying that there isn't case where bouncing is appropriate, but I am hard pressed to think of one, and it makes sense to try to avoid it wherever possible. Peter
Re: force startssl/tls/ssl on sasl login
On 11/07/2013 08:38 PM, nik600 wrote: > > you can auth using STARTSSL on standard port 25 Port 25 should be for MX to MX communication, not for submission. > you can auth using TLS/SSL on standard port 465 Port 465 is SMTPS which is deprecated. You should be using the submission port (587) with STARTTLS for submission. There is a commented example in your master.cf file. You can safely force encryption on this port because you don't need to worry about inbound mail from other MXes. Peter
Re: Postfix Repos
On 11/14/2013 06:16 AM, Steffan A. Cline wrote: > Does anyone know of any good bleeding edge postfix repos? > > I am using whatever the CentOS distros come with and it appears to be an > older version. postfix 2.10.2 is in the ghettoforge gf-plus repo for both CentOS 5 and CentOS 6 and is built with postgresql, mysql and ldap support: http://ghettoforge.org/ Peter
Re: Do not send mails to addresses with more than 3 dots in username part
On 11/23/2013 12:38 AM, Alexander Farber wrote: > So the following seems to work for me for now - > > /etc/postfix/header_checks: > > /^To: \S+\.\S+\.\S+\.\s...@gmail.com <mailto:s...@gmail.com>$/i DISCARD > > /etc/postfix/main.cf <http://main.cf>: > > header_checks = pcre:/etc/postfix/header_checks Header checks will certainly work, but it requires that postfix does deep inspection of the message DATA in order to and before it can reject the message. You're much better off checking the envelope recipient with a check_recipient_access restriction. This too can use a pcre table so you can match the recipient address against a regular expression with three dots, then postfix won't have to do deep inspection of the DATA packet, and can reject the mail at the RCPT TO stage before the DATA is even transmitted to postfix, much more efficient. Note: Others have stated that this should really be done in your web app, and I agree with that, but I won't go into that as you seem to clearly indicate that you just want postfix advice here, so my advice is that if you *must* do it in postfix, then you should use check_recipient_access instead of header_checks. Peter
Re: Do not send mails to addresses with more than 3 dots in username part
On 11/23/2013 11:08 PM, Alexander Farber wrote: > > thank you! So I have moved the line > > /^To: \S+\.\S+\.\S+\.\s...@gmail.com <mailto:s...@gmail.com>$/i DISCARD > > to the file /etc/postfix/access, but when I run > > # postmap /etc/postfix/access > > I get the warning: > > postmap: warning: /etc/postfix/access, line 452: record is in "key: > value" format; is this an alias file? I assumed that when I made the suggestion you would go and read the docs for check_recipient_access which would have told you that check_recipient_access is a smtpd_recipient_restricion, that it checks against the envelope recipient address (as opposed to a header), and that the format of the table is documented in access(5). If you had gone on to read the access(5) man page then you would have seen the correct format for your file. I won't go into detail on what failed, though, because Weitse already gave you that answer. Peter
Re: Do not send mails to addresses with more than 3 dots in username part
On 11/24/2013 08:18 AM, tejas sarade wrote: > > You can use the DISCARD instead of REJECT. I wouldn't recommend that, unless there is a very specific reason for it as a rule of thumb it's rarely a good idea to DISCARD mail. In this particular case REJECT will work just fine, REJECT followed by a reason would be even better. Peter
Re: Do not send mails to addresses with more than 3 dots in username part
On 11/24/2013 08:25 AM, li...@rhsoft.net wrote: > > have fun with "reject_unauth_destination" too late and > "check_recipient_access" says "PERMIT" instead "DUNNO" > > a major mistake and becuase it is made too often smtpd_relay_restrictions > was included in the lastest releases > > http://www.postfix.org/SMTPD_ACCESS_README.html#danger >From the original post: > I run a Drupal 7 website on a CentOS 6.4 server with > postfix-2.6.6-2.2.el6_1.x86_64. smtpd_relay_restrictions was not introduced until postfix 2.10. At any rate, he should be safe as long as there are no PERMIT actions in his pcre_recipients file. Peter
Re: how to make postfix alter the "From" header on outbound messages to mat IP
On 11/27/2013 12:59 PM, l...@airstreamcomm.net wrote: > > An unusual server rejects mail on the basis that the domain portion > of the FROM address in the header does not match the IP address of > the server. What's the server? What's the domain name in the email address that's being rejected? It could very well be that you have an SPF record that specifically tells other servers to reject your mail. Peter
Re: Permit SASL authenticated users to bypass DMARC
On 03/17/2014 11:08 PM, Oriental Sensation wrote: > Birta, > > Thanks for the prompt input. I think the correct way is the following, > though: > > smtps inet n - n - - smtpd >-o smtpd_milters=inet:smtp:10025 > > Which basically will apply DKIM signatures but jump over DMARC auth. You're confusing smtps with smtp. You likely shouldn't be using smtps at all. Peter
Re: Can I reject when sender doesn't appear in from: header?
On 03/28/2014 10:16 AM, Adam Moffett wrote: > I'm seeing messages occasionally where the envelope sender is a > verifiable address at someone else's domain, but the from: header > contains some non-existent user @ our local domain. This is a very bad idea, to illustrate why here is the envelope sender of your message (that I'm replying to): Return-Path: ...and here is the From: header: From: Adam Moffett Obviously the two don't match, and equally obvious is that your message is not SPAM. Peter
Re: Can I reject when sender doesn't appear in from: header?
On 03/30/2014 01:25 PM, li...@rhsoft.net wrote: > > while i agree that it is a bad idea to take headers into account I wouldn't say that, it depends on exactly what you're doing and how much you're basing your decision to reject on that single piece of data. > as well as Barracuda networks started to do the same with their > last firmware and so the spoofing protection kills *any* mailing > list What barracuda did was different, they used a policy list for deep inspection of Recipient headers and rejected based on that which caused problems because a policy list is only supposed to be checked against the client connecting directly to your MX, not every IP in the Recipient list. > you missed "contains some non-existent user @ our local domain" I was mainly basing my comment on the subject, "Can I reject when sender doesn't appear in from: header?" > however, mail is about SMTP and SMTP is about envelopes I wouldn't exactly say that either, and don't feel the need to go into all the different levels that statement fails in. Peter
Re: v4bl.org anyone knows this ?
On 04/12/2014 03:07 AM, Robert Schetterer wrote: > Hi , anyone knows this rbl ? > > http://v4bl.org/about.html My experience with them isn't very good. They brag about the large number of IPs they have and keep adding to the list, but for a DNSRBL quality is much more important than quantity. I have had dealings trying to get some servers removed from their lists and they refused with the following reason: "Those IPs remain listed because the underlying domain lacks the credibility/responsibility required of any outbound email sending system (i.e. an ESP)." Not very clear and basically they're saying that because we're not an ESP they're going to blacklist us. Personally I would not recommend that anyone use this DNSRBL unless you want to be blocking a large portion of legitimate mail. Fortunately my experience is that hardly anyone actually does use them, so being on their list is not the end of the world. Peter
Re: How to block offering SASL auth to clients based on RBL
On 06/08/2014 03:53 AM, li...@rhsoft.net wrote: > well, one could say: block them from submission port and don't allow > SASL on 25, but that works only if you are a startup beginning from > scratch, i condsidered that but it would take weeks and months to > explain all customers that they have to fix their client configs > and i see even new configured clients using 25 because the idiotic > MUA's still default to 25 and burrie the port setting somewhere > under "expert" or "extended" settings, so you can't do that if > you have hundrets of customers with all sort of devices If that's the case then you can put submission on a separate IP address, so that your users can continue to submit to port 25 (and indeed even to the same hostname on port 25) without problem, and it that service will not have to handle MX traffic. In addition to the postfix configuration changes this only requires (1) a free IP address and (2) DNS change. Peter
Re: How to block offering SASL auth to clients based on RBL
On 06/08/2014 08:53 AM, LuKreme wrote: > >> the stupidity is trying 25 first > > That is still what most servers support or even require. I think the vast number of ESPs will accept submission on port 587. Only supporting port 25 for submission nowadays is a disaster considering the number of ISPs that block outbound port 25. Many will still offer 25 for backwards compatibility, but even those will use a separate IP address in the vast majority of cases so as not to mix submission with MX traffic. Peter
Re: How to block offering SASL auth to clients based on RBL
On 06/09/2014 04:56 PM, li...@rhsoft.net wrote: >>> well, one could say: block them from submission port and don't allow >>> SASL on 25, but that works only if you are a startup beginning from >>> scratch, >> >> If that's the case then you can put submission on a separate IP address, >> so that your users can continue to submit to port 25 > > "so that your users can continue to submit to port 25" > > and how will that lead to "close port 25 completly"? So on the one hand you complain about how difficult it is to switch users off of port 25, but then when I give you a solution that means you don't have to you complain because you don't want them on port 25? Make up your mind, please. > my server has not to handle *any* MX traffic from outside, Then I fail to see what the problem is. > besides that you gain nothing why in the world should admins > deal with all sort of workarounds because MUA developers are > too stupid for sane defaults and insist in use 25? Please, go to Microsoft, Apple, Google, etc, and convince all of them to write their software the way you want. Unfortunately we live in the real world and this is what we have to deal with. Depending on your specific situation you may or may not have to cater to those MUAs. > frankly *all* ISP's should start to block outgoing port 25 I would love to see that, but again, we live in the real world. > and the problem would go away at the same time as 90% of > attempted spam delivery would disappear because all the > infected zombies have no longer a way to send their crap > without hacking the acount data and use real submission PBLs, FCRDNS, etc help a lot with this as well. Postscreen, when properly configured, is great at filtering zombie SPAM. The harder SPAM to filter tends to be SPAM that originates from legitimate servers, as you have said. > the difference ISP is blocking 25 or i do the same is simply > that nobody calls the ISP but anybody blames his mail admin > which can help in both cases but in one point to the ISP :-) Regardless of who is blocking it you have to deal with the results. As I said earlier you may be in a position where you can just block 25 outright and be able to push all your users to submission, or this may be too overwhelming of a task. The difference is that if the ISP blocks it then the user is *already* on 587. Peter
Re: How to block offering SASL auth to clients based on RBL
On 06/08/2014 08:17 PM, Kai Krakow wrote: > MX and Submission machine are the same postfix instance (and even the same > worker process on port 25), it won't work. I'm planning to maybe change this > in the future. But as with migrating all people to not submit on port 25 it > is a long way to go. If you can't force your users off of port 25, then the next best thing is to separate our your submission by IP address, if done correctly your users will be able to stay on port 25, not have to change the hostname (or any other settings in their MUA) and you will have separated out submission from MX traffic and can treat the two with different configs. Peter
Postfix IRC chat support moving to Libera chat
Just to let everyone know we are moving IRC chat support from Freenode to Libera chat. If you'd like community support for postfix via IRC please join us at irc.libera.chat #postfix: https://libera.chat/guides/connect For more info about why we have moved please see: https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 Peter
Bug: Postfix errors at startup for service listed in known_tcp_ports but not listed in /etc/services
Just had someone come into the IRC chat with this issue and I was able to reproduce it quite easily, this is with Postfix 3.6.2. If your /etc/services has smtps listed but not submissions (or vice-versa) and you uncomment or add the relevant section to master.cf then postfix gives an error like the following at startup: Oct 17 18:28:59 CentOS8 postfix/master[79810]: fatal: 127.0.0.1:submissions: Servname not supported for ai_socktype Oct 17 18:29:00 CentOS8 postfix/master[79809]: fatal: daemon initialization failure Oct 17 18:29:01 CentOS8 postfix/postfix-script[79811]: fatal: mail system startup failed ...the thing is that submissions is listed in known_tcp_ports: known_tcp_ports = lmtp=24, smtp=25, smtps=submissions=465, submission=587 ...so by rights postfix should know that submissions is port 465 and startup without error in spite of the service not being listed in /etc/services. Is there a stray startup check that was missed when known_tcp_ports was added or something? Peter
