postfix package for pfSense 2.3

[marcelloc]

No description provided.

[rbgarga]

Packages will never be allowed to touch system files anymore. It's wrong and dangerous

[marcelloc]

How can I change syslog conf to maillogs on 2.3?

Is the a function for this?

[rbgarga]

There is an implementation also on 2.2 for this, as you can see at https://github.com/pfsense/pfsense/blob/master/src/etc/inc/system.inc#L889

[nerdalertdk]

Why u no merge

[spawn-v1]

Is there a time-line for the postfix package on PfSense 2.3?

[aes512]

+1 .. any timelines guys?

[FeKn]

Are there any problems to merge this pull request?
The only obstruction for me to upgrade to 2.3 is the missing postfix package...
Thx

[ackstorm23]

[dneuhaeuser]

+1 waiting for this package!

[PhilBiggs]

It would be great to get this package back on the list.

[rstevens011]

I'll add my support as well. It would be nice to see this merged.

[andrewmcgilvray]

I would love to be able to use this too.

[cmhamm]

This branch appears to have been ready to go for some time, and we're looking for a highly available MTA to deploy. We already use pfSense for our VPN and HAProxy, it'd be great if we could install this package and be done with it. Is it just waiting for approval? Anything we might be able to do to help move it along?

Thanks in advance!

[PhilBiggs]

Could we please just have a clear statement about whether the intention is to merge this package or not?

[whoot]

This package is ready to branch since december 2015 and still not available in Pfsense.
How much longer do you guys need to merge this branch?

[lsarakinos]

Please include it in the packages.
We are waiting this to have upgrade from 2.2.6 to 2.3.x
Combined with mailscanner is the perfect combination for small business front end MTAs.

[spec1re]

+1

[kahisfz]

Waiting for approval

On Sep 1, 2016 5:34 PM, "spec1re" notifications@github.com wrote:

+1

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJE3hoCQ6uR3WMN_LPznGWvB2leUMJjKks5qlsZsgaJpZM4GzEjq
.

[cmhamm]

It's been waiting for approval for 9 months - I'm being patient, but I'm also hoping that maybe some of this discussion might spur things along a little bit. 😄

[sbraz]

@rbgarga any chance to make this move forward?

[svenauhagen]

Hi,
I could not find it in the source by browsing over it. Does your package support amavis/spamassassin/clamav?

Thanks
Sven

[ghost]

Please merge!

[rbgarga]

After many internal discussions, we (pfSense developers) decided that we are not bringing an MTA to pfSense again.

[dneuhaeuser]

what are the reasons for this decision?

[cmhamm]

All of the pfSense devs have done such a great job with the software that I wouldn't go so far as to say this is a mistake, however, I too would like to know a little bit of the internal reasoning.

My thoughts are as such: pfSense is designed a gateway device, on the edge of network. pfSense really doesn't need to be a full MTA, however, it does make perfect logical sense for it to provide relay functions from the internal network out to the Internet. My intention was to set up postfix so that we could block standard email ports and require that everything inside of our network send outgoing mail to the pfSense box. Due to the excellent CARP and XMLRPC Sync, it would provide a fault-tolerant, HA mail relay that could, in theory, trigger alerts if anything suspicious was trying to relay email from within our network.

Of course there are many other ways to accomplish this goal, and we have already implemented one of these methods, but it I do believe there is a good case for being able to include this in pfSense.

Again, I'm not trying to start an argument - just curious about the reasoning behind the decision.

As always, thank you to the developers who contribute to this project. It is of enormous value to many, many people, and is still (and always will be) my go-to firewall.

[ackstorm23]

I am guessing its the usual answer - fear of it being abused by lazy admins who don't follow best practices. Strange though that they allow bind to make it in, when the same thing could result.

[cmhamm]

All admins are lazy. It's why we choose to be admins. 😆

[nerdalertdk]

Well sad to see the forward of mail options gone :(

[kahisfz]

The decision you made today will effect PfSense very shortly, please
declare it as a full commercial product under your own license as this
decision already reflects the close mindedness of men in suits. Opensource
software community is always open and works for the knowledge.
I wish you good luck but certain that few more decision like this and you
are done.
Anyway best of luck with sense and wish you have more wisdom.

On Wed, Sep 14, 2016 at 7:19 PM, Dennis Neuhaeuser <notifications@github.com

wrote:

what are the reasons for this decision?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJE3hr5O1OqtmIeYMxI6e8otRATIVw1dks5qqAJbgaJpZM4GzEjq
.

[dennypage]

I don't speak for the devs, but I will say that I respect their decision.

I think it's important to keep in mind that pfSense is a network security device. It's principal purpose is as a firewall. As a firewall, pfSense begins with a certain minimum attack surface, and every added package increases the attack surface. This is particularly true of packages with open ports, most especially those that open ports on the WAN interface. These things need to be restricted to those that are truly necessary, either because of pfSense's location in the network or because they are needed for basic operation of the firewall itself. Something with the complexity of Postfix with an open WAN port creates a huge increase in the attack surface. ClamAV represents another huge increase. And there is no compelling reason for Postfix/ClamAV to be run on the firewall--it can be run elsewhere without capability loss.

Some will say "well, let me make the choice!" and I understand the sentiment. But the vast majority of users are not able to properly evaluate the substantial security risk associated with such a choice. They look at the packages distributed as part of pfSense and assume that they are relatively safe. After all, they wouldn't be part of pfSense if the were not safe would they? As leaders of a firewall project, the pfSense devs have a substantial responsibility to those users. This responsibility sometimes means having to step up and make hard decisions. And that's what they have done. You may not agree with the decision, but you should respect it.

Btw, ackstorm23 you make a good point about Bind. Although it is now one of the most throughly reviewed pieces of code you can find, It probably isn't something that should be part of pfSense. NSD perhaps, but not bind. :)

[rbgarga]

There is a big difference between bind and postfix. Bind is a single service while postfix package is a combination of programs (postfix, spamassassin, clamav, amavis, policyd, ...). It also requires changes on core to disable clog. It's too big for something that is definitely not primary function of pfSense software.

That is the main reason we decided to decline it.

[SukMeWot]

Sorry but I think this decision is short sighted. This app provides the perfect front door to any internal mail server. If all you want pFSense to be is a firewall then get rid of the other applications too such as routing, snort, web filtering etc etc.

I've used pFSense simply because it means I don't need to configure half a dozen boxes, this app forms part of that strategy - the ability to turn pfSense into an MTA is what makes it so powerful - declining this app is a decision that is mystifying. Postfix is only a collection of app's if you choose to do so.

If I need to go back to configuring a dozen boxes to achieve what I need then I'm afraid pfsense won't be one of them and I'll stop recommending it to customers.

So do us a favour and start being more honest about why some apps are in and some are out - the pfSense team are startting to show the same arrogance in its decisions as some of the bigger 'commercial' players.

[cmhamm]

I would also, humbly, ask that the devs keep in mind that the original reason pfSense was forked from m0n0wall was because m0n0wall was "just a network security device." pfSense was supposed to be a more feature-rich install, with a slightly larger footprint, but without all the bloat of something like IPCop or ClarkConnect.

I still believe in the mission - I just hope that the features that make pfSense such a great and flexible platform aren't removed, one by one, until we're back to m0n0wall.

[mrvanity]

I have to say that this decision has troubled me.
Blocking malicious and spam messages is a vital part of a network security device.
I guess this is the logic behind allowing HAVP on pfsense.
This was the logic until a year ago that postfix worked.
Please think of reconsidering.

[cmhamm]

This has actually led me to an important question, which I hope that the developers are willing to answer openly and honestly:

I'm making system design decisions right now for our network. While we hadn't implemented postfix yet, we're getting ready to purchase and deploy some pfSense appliances for use with HAProxy, as well as some other instances for use with Squid proxy, both in HA configurations. We also rely on the OpenVPN module very heavily in our network.

Does this decision to remove postfix from future updates indicate a general shift in the direction pfSense is headed? Do you envision removing other "heavy" components in pfSense, to transition into more of a m0n0wall type, single-purpose device? I'm not asking to be critical or express disappointment. I've been pushing hard for our management to purchase pfSense appliances as well as support over the next few months, and I want to ensure that these devices will continue doing what I'm planning to use them for, including updates and support in the future.

[SukMeWot]

Wouldn't waste your breath - the devs are headed down a different path with pFsense now - they've forgotten why it forked from m0n0wall in the first place. Perhaps we need to repeat the process and follow our own path - alas I haven't the time - wish I did.

[aes512]

@SukMeWot I totally concur. This is why have had to migrate to OPNsense recently.