Re: Procmail Vulnerabilities check

[emilia]

December 11, 2017 7:39 PM, "Kurt Jaeger"  wrote:

> The argument is: The update process for base is more complex
> than for packages, and we've come a long way to have a very
> nice pkg-system, in general. The mid-term plan is thus to package base, too.

The non-packaged base is one of the primary reasons I switched from debian to 
FreeBSD :)


regards,
emilia
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Dan Langille]

> On Dec 13, 2017, at 12:27 PM, Christoph Brinkhaus  
> wrote:
> 
> On Wed, Dec 13, 2017 at 11:35:55AM +0100, Jos Chrispijn wrote:
>> On 8-12-2017 17:58, Warren Block wrote:
>>> procmail is ancient, and has had known quality issues for much of the 
>>> time.  Consider maildrop as a more powerful and more maintained 
>>> replacement that is pretty easy to implement:
>> I know - but I can remember that procmail should be installed also when 
>> using Postfix.
>> Might be wrong here...
> 
> Dear Joe,
> 
> I have replaced procmail by maildrop recently using it with Postfix.
> There has been just one single obstacle. I run fetchmail as suer
> fetchmail started with the entry in /etc/rc.conf. The mails have been
> delivered to Postfix which involked procmail to distribute the mail.
> 
> With maildrop this did not work initially. Adding the user fetchmail
> to /etc/aliases with a proper alias address followed by the command
> newaliases fixed that.

I like such replacements.

However, if third party code is required, there is little we can do in the 
short term.

Case in point: security/logcheck.

I went upstream looking to see why Debian uses that.

I cannot recall exactly what it was, but it wasn't procmail, but another 
utility provide by procmail.

I stopped there.

-- 
Dan Langille - BSDCan / PGCon
d...@langille.org



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Christoph Brinkhaus]

On Wed, Dec 13, 2017 at 11:35:55AM +0100, Jos Chrispijn wrote:
> On 8-12-2017 17:58, Warren Block wrote:
> > procmail is ancient, and has had known quality issues for much of the 
> > time.  Consider maildrop as a more powerful and more maintained 
> > replacement that is pretty easy to implement:
> I know - but I can remember that procmail should be installed also when 
> using Postfix.
> Might be wrong here...

Dear Joe,

I have replaced procmail by maildrop recently using it with Postfix.
There has been just one single obstacle. I run fetchmail as suer
fetchmail started with the entry in /etc/rc.conf. The mails have been
delivered to Postfix which involked procmail to distribute the mail.

With maildrop this did not work initially. Adding the user fetchmail
to /etc/aliases with a proper alias address followed by the command
newaliases fixed that.

Kind regards,
Christoph
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Carmel NY]

On Wed, 13 Dec 2017 11:35:55 +0100, Jos Chrispijn stated:

>On 8-12-2017 17:58, Warren Block wrote:
>> procmail is ancient, and has had known quality issues for much of the 
>> time.  Consider maildrop as a more powerful and more maintained 
>> replacement that is pretty easy to implement:  
>I know - but I can remember that procmail should be installed also when 
>using Postfix.
>Might be wrong here...

A Postfix / Dovecot with sieve combination is a far more powerful combination
and it is fully supported.

-- 
Carmel


pgpDMxAMyvSDJ.pgp
Description: OpenPGP digital signature

Re: Procmail Vulnerabilities check

[Jos Chrispijn]

On 8-12-2017 19:11, Kurt Jaeger wrote:
We'll work the patch in, it just takes a little time 8-( 


Thanks for this - everything is fine now.
Keep up the good work,
Jos
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Jos Chrispijn]

On 8-12-2017 17:58, Warren Block wrote:
procmail is ancient, and has had known quality issues for much of the 
time.  Consider maildrop as a more powerful and more maintained 
replacement that is pretty easy to implement:
I know - but I can remember that procmail should be installed also when 
using Postfix.

Might be wrong here...

Thanks, Jos

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Tue, 12 Dec 2017 09:23:55 +0100 "Kurt Jaeger"  said


Hi!

> > With transparency, I mean:
> > - reverse dns is set
> > - scan from the same IP all the time
> They don't. For the sake of argument, I'll name showdan; they use (off
> the top of my head) some 9 to 12 addresses. Addresses the move, also. :(

If their IPs are published somewhere in a parseable format,
I'm fine if it's multiple IPs or if they move etc.

> > https://github.com/TLS-Check/tls-check
> I respectfully agree to disagree with you on this. Mostly on one point;
> I should be informed *prior* to the port scan/audit, not *after*.

What type of announcement on what list/forum/irc-channel would you
accept/monitor/etc ?

Would it be sufficient, if the PTR record has some TXT that points
to the official site with the details of the scan ? So that
during incoming scans you can automatically look up the source
of the scan ?

That would differentiate a research scan from an attack scan, wouldn't it ?

Given that most attackers scan unannounced, and systems have to handle
that case, I do not see the problem in scans being done unannounced, btw.

OK My knee-jerk reaction is; there is no such thing as a "good" broad based
scan -- ever. But big data is all the rage these days. So that kind of data
is worth big bucks, and everybody wants a piece of the action.
The scan I found most offensive, was conducted by IANA (as memory serves).
It was just around the time chicken little was screaming the IP4 address
exhaustion sky was falling. What I found most offensive about it, was that it
was performed by one of the root servers. I have all the data somewhere,
including some log excerpts. But I'm not going to have time to try and find
it this morning. The purpose, again, as memory serves; was to see how much
of the IPv4 address was actually being used, and what for. Frankly, I say
bullshit! Again, I could liken it to real life situations; I bought an
automobile from a car dealership, only to find later, that they've put some
monitoring device in it, that tracks everything done with, and in it. OK
that may not have been the best example; as one could argue that the onboard
computers in newer cars are already capable of doing much of that, already.
But I think you can see my point -- privacy should always be respected, and
any (potential) violation should avoided. It should be an "opt in". One should
have the opportunity waive their rights to privacy. By virtue of being connected
to the internet, does not, nor should not assume you no longer have the final
say on your termination point on the vast network called the internet. Sorry.
I know the preface is a bit long. But I wanted to be clear, and this was as
concise as I could get. I wanted to cover all the bases before articulating
my responses to your questions. Using (any) of the root servers to perform
such tasks is especially egregious, given that we *depend* (see; require) them
to keep the internet functional. So it's harder to justify blocking all traffic
from their location.
I guess I've probably already answered your questions. But to address them
specifically;
ICAN/IANA should probably have a registry for any/all so-called; above board
scanning projects/initiatives/skript-kiddies. IOW, if such a thing should/could
be considered "acceptable". One should be *required* to register at IANA.
They must be required to fully explain their purpose, their intent, how they
intend to perform it, they should also be required to produce a schedule,
including the times, and dates, and what the data will be used for. The last
item is the one I find most troublesome. The chance that data will not be shared
is next to nill. That that data won't be used for reasons *you* as a target,
don't approve of, is next to nill. But if it is to ever be "permissible". Those
should be the minimal terms. A fee must be required. This will help ensure that
IANA can maintain, and enforce these requirements, lessen the likelihood that
anyone do any of this on a whim. Lastly; for the "target". IANA must one)
make the registry, and it's content public. two) IANA should create an RSS,
and a list-feed, that the potential targets can subscribe to. Oh, and there
should be some (further) restrictions imposed on the registrants regarding
(at least) the load(s) they may impose upon their targets/victims. OH, you
asked about (DNS) TXT entries. That would help, I suppose. In fact, as memory
serves, that's what they (IANA) did in the one I mentioned above. But I think
that's far too little, and ends up too late. Registration, and guidelines
are the only thing that can even come close to making any of this seem even
slightly tolerable, and even then... :-)
Sorry. This turned out much longer than intended. I'm afraid I did all this
as it came to me. Rather than better formatting it all. Hope you, and others
will forgive me. My intents were pure. :-)

All the best to you, Kurt!

--Chris



--
p...@opsec.eu+49 171 3101372  

Re: Procmail Vulnerabilities check

[Chris H]

On Tue, 12 Dec 2017 08:59:04 +0100 "Guido Falsi"  said


On 12/09/2017 01:34, Chris H wrote:
> On Sat, 9 Dec 2017 10:16:54 +1100 (EST) "Dave Horsfall"
>  said
> 
>> On Fri, 8 Dec 2017, Steve Kargl wrote:

>>
>> > First, there is movement afoot to remove sendmail from FreeBSD and >
>> replace it with dma(1).
>>
>> There is?  Is there anything else that they're going to spring on us?
>>
>> (I'm still annoyed that they removed "jive" because it upset someone's
>> delicate sensibilities.)
> Hmm. This does not come as good news to me. I've been working on an
> antispam
> system that targets the use of Sendmail, for about a year (not counting the
> untold hours spent tuning it over the years). Sure, many aren't comfortable
> with the m4(1) macros. But c'mon. Please don't.
> As to these backstage removal discussions; is it remotely possible that
> those of whom continue to use, and contribute to *BSD after all these years
> might be included in these discussions?

I just chime in to point out that the discussion is not happening in any
backstage.

The proposal was sent to the arch mailing list, which is public. I'm not
subscribed to it either but I was pointed there by a fellow user.

https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html

Indeed, and thank you, Guido.
I'm not subscribed either, and find myself puzzled as to that choice of lists
to make the announcement. But then again, what do I know. I still want to keep
it in base. :-)

--Chris


--
Guido Falsi 



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> > With transparency, I mean:
> > - reverse dns is set
> > - scan from the same IP all the time
> They don't. For the sake of argument, I'll name showdan; they use (off
> the top of my head) some 9 to 12 addresses. Addresses the move, also. :(

If their IPs are published somewhere in a parseable format,
I'm fine if it's multiple IPs or if they move etc.

> > https://github.com/TLS-Check/tls-check
> I respectfully agree to disagree with you on this. Mostly on one point;
> I should be informed *prior* to the port scan/audit, not *after*.

What type of announcement on what list/forum/irc-channel would you
accept/monitor/etc ?

Would it be sufficient, if the PTR record has some TXT that points
to the official site with the details of the scan ? So that
during incoming scans you can automatically look up the source
of the scan ?

That would differentiate a research scan from an attack scan, wouldn't it ?

Given that most attackers scan unannounced, and systems have to handle
that case, I do not see the problem in scans being done unannounced, btw.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Guido Falsi]

On 12/09/2017 01:34, Chris H wrote:
> On Sat, 9 Dec 2017 10:16:54 +1100 (EST) "Dave Horsfall"
>  said
> 
>> On Fri, 8 Dec 2017, Steve Kargl wrote:
>>
>> > First, there is movement afoot to remove sendmail from FreeBSD and >
>> replace it with dma(1).
>>
>> There is?  Is there anything else that they're going to spring on us?
>>
>> (I'm still annoyed that they removed "jive" because it upset someone's
>> delicate sensibilities.)
> Hmm. This does not come as good news to me. I've been working on an
> antispam
> system that targets the use of Sendmail, for about a year (not counting the
> untold hours spent tuning it over the years). Sure, many aren't comfortable
> with the m4(1) macros. But c'mon. Please don't.
> As to these backstage removal discussions; is it remotely possible that
> those of whom continue to use, and contribute to *BSD after all these years
> might be included in these discussions?

I just chime in to point out that the discussion is not happening in any
backstage.

The proposal was sent to the arch mailing list, which is public. I'm not
subscribed to it either but I was pointed there by a fellow user.

https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Tue, 12 Dec 2017 08:54:26 +1100 (EST) "Dave Horsfall"  
said


On Mon, 11 Dec 2017, Chris H wrote:

> pf(4) has dropped any/all communication from the showdan "project" 
> *long* ago for all the systems I'm responsible for, and along with all 
> the myriad of other "like" projects. They all have the policy backward; 
> ask *before* not *after*.


I'd love to do that; what's the IP range of their scanners (I assume that 
they have more than one)?

Sure. I'll pull them out of my tables, and send you a copy off-list.


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."


--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Dave Horsfall]

On Mon, 11 Dec 2017, Chris H wrote:

pf(4) has dropped any/all communication from the showdan "project" 
*long* ago for all the systems I'm responsible for, and along with all 
the myriad of other "like" projects. They all have the policy backward; 
ask *before* not *after*.


I'd love to do that; what's the IP range of their scanners (I assume that 
they have more than one)?


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 20:45:11 +0100 "Kurt Jaeger"  said


Hi!

> Let me attempt to make my point another way (and stay closer to topic).
> A user is able to accomplish more from sendmail in base, than with any
> other MX port in base alone.
[list of sendmail features shortend for brevity]

> Many of the other MX software in the ports tree provide a subset of
> the shortlist I mentioned above. But none of them offer them all.

So if sendmail is a pkg/port, it would still have those features ?

Is a

pkg install sendmail

such a huge step ? And btw, even if sendmail has all those features,
I can tell you that even when I first attend my first sendmail workshop,
approx. 27 years ago, I still would not know how to implement them
with sendmail.

> I were an MX administrator. Would I not want all the options/help
> I could get to defend myself against attack?

I still don't get the difference if sendmail would be a port/pkg.

Oh, btw, if sendmail can do all this, wouldn't it be useful to
have a suitable config that does all this right out of the box ?

Because, honestly, I would not know how to enable all those features...

> True. But if I'm selling a Server targeted OS. Don't I want to
> advocate server grade services?

But the distribution channel of the software for that service
(base or port) does not sound as the relevant factor for the
end-user, or does it ?

OK. So if I'm understanding this all correctly; All the (FreeBSD) worlds
a package. So what am I arguing for Sendmail in base for? It makes no
sense -- everything's a package. Am I getting warmer? :-)
If so. Then where does it end? How many packages must I install to get a
"standard" Server install? I'm going to want cp(1), fsck(8), mkdir(1),
gpart(8),...
Wow! filling /bin/, and /sbin/ will take an awful lot of packages, and I
haven't had time to consider /usr/bin/, and /usr/sbin/ ! ;-)
As I understand it, the $BASE package is going to amount to what one
would expect, and need to get (at least) a usable system. IMHO *mail*
is an important part of *any* system. Oh wait. This is intended as part
of a simple *desktop* system? Because that's the audience FreeBSD is
currently targeting? OK than no *real* need for a robust MX there. As
they'll likely just be using their ISP for an MX, and only *really* need
a MX *client*. OK that makes more sense. :P
I'm only advocating that if $BASE is intended for a reasonable/minimal
Server base install. That an MX *is* an important part of that definition,
and that Sendmail be *that* MX. :-)

Thanks for playing along, Kurt. :-)

--Chris

P.S. Indeed. Sendmail, *can* be installed as a package, and still work,
as I think, can *anything* else. But *where* does it all end -- It's
*mad* I tell ya!


--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 19:46:55 +0100 "Kurt Jaeger"  said


Hi!

> If you, as an administrator of a/your system(s), see no problem with
> (port) scanners, and take no action to thwart such activity. You are
> more than likely to encounter trouble(s) down the road.

Right, portscanning is bad, if not done in a transparent way,
so as sys-admin I have to reduce exposure.

But it's a valid tool, nevertheless.

> In short; I see them all as "black hats". Honestly. Can you *really*
> determine good intentions from bad intentions on an incoming port scan?

Yes. If it's done with full transparency, I don't mind scanning.

With transparency, I mean:
- reverse dns is set
- scan from the same IP all the time

They don't. For the sake of argument, I'll name showdan; they use (off
the top of my head) some 9 to 12 addresses. Addresses the move, also. :(


- some point of contact for the scan (a website, email etc)
- if requested, the scanner delivers individual results to the scanned
- if requested, one can be excluded from the scan
- all the results are only used for 'above-the-waterline' work,
 like research or statistics
- scanner is willing to be audited
- [maybe some other rules...]

In fact, I've even organised such a project doing that for TLS:

https://github.com/TLS-Check/tls-check

I respectfully agree to disagree with you on this. Mostly on one point;
I should be informed *prior* to the port scan/audit, not *after*.



I would not mind a registry at IANA for such transparent scan projects,
so that all the other ones can be traced and stopped.

This, my friend, I agree with you on, wholeheartedly. :-)

--Chris



--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Roger Marquis]

Michelle Sullivan wrote:

Personally I think if you remove Sendmail you should not replace it with
something else... but then FreeBSD is not about what I want or what the
users want anymore.


I thought there already was a viable replacement in OpenSMTPD?  The fact
that OpenBSD migrated 3 years ago makes this a no-brainer, or does
anyone think accepting mail from remote hosts needs to be part of base?

Considering just about every other open source OS distribution now uses
Postfix the potential for its license to be updated (from IPL to EPL2.0)
may be timely...


Roger
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 19:36:49 +0100 "Kurt Jaeger"  said


Hi!

> if the majority of people install their systems via packages, that makes for
> a fairly common FreeBSD base across all users.

Why would a system installed via packaged be more homogenous than
one installed as base, and updated via freebsd-update ? I don't
understand this -- can you elaborate ?

OK. I'll try. I'm afraid I sort of went on a Jag, and didn't really make a good
point -- if *any* point. Sorry.
But to the point, and sorry for the (additional) deviation;
If I have a user base that shares a near identical install. I am far closer
to finding/having a pattern I can work with to *exploit*, as an evil hacker.
So here's the thing; working from the history of Linux, and for that matter,
even MS products... someone discovers an exploit in FreeBSD, or some component
common to FreeBSD. I can take down a *much* greater number of users, now that
the (larger) portion of FreeBSD' user base share such a common install base --
applications(ports)/kernel et al; are pretty much all the same for *everyone*
because of the introduction of pkg(8).
Yes. But what's the difference if they made everything from ports(7)?
IMHO, and experience, users confronted with options during build time, are
*more* likely to actually *choose* options that better suite their use/needs.
But using packages is easier, and so if in the end everything just *works*.
There's little incentive to use that scary "make" thing, and have to learn
all those intimidating things associated with the ports system.
Well, FLAVORS should solve all that. Wouldn't it?
That *does* seem like a strong argument, and while I applaud all the efforts,
and those that are responsible for those efforts. The jury is still out.
FLAVORS has yet to *fully* arrive. So it's just too early to say for sure.
But I would agree that it *should*.
When I look back at all the security threats that Linux had to deal with
(even now), and how the ultimate argument was so often; use *BSD, it's a
much more secure OS by design. Which was true. Linux was/is always installed
in packages, or by what ever moniker they use for them. With that, and their
choice of kernel arrangement. They were left as easier targets than the BSD
family of operating systems. Now looking at the increasingly narrowing of
differences between the two. I can't help but think that the threat vector
gap is *also* narrowing.



> In closing, and more to the point regarding Sendmail; Sendmail has a nearly
> impeccable security record in at the last decade. It provides a *secure*,
> more powerful, and more flexible MX on the cheap. I see little reason to
> consider it an attack vector. Which makes *security*, and it's related
> maintenance a pretty poor argument, for it's removal.

The argument is: The update process for base is more complex
than for packages, and we've come a long way to have a very
nice pkg-system, in general. The mid-term plan is thus to package base, too.

Packaging base means sensible packages have to be defined, and
sendmail suits a package very well.

Indeed it *does*, and *should* be a package installed *along* with $BASE.
That's my only argument there. :-)

Thanks for your thoughtful reply, Kurt!

--Chris


--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> Let me attempt to make my point another way (and stay closer to topic).
> A user is able to accomplish more from sendmail in base, than with any
> other MX port in base alone.
[list of sendmail features shortend for brevity]

> Many of the other MX software in the ports tree provide a subset of
> the shortlist I mentioned above. But none of them offer them all.

So if sendmail is a pkg/port, it would still have those features ?

Is a

pkg install sendmail

such a huge step ? And btw, even if sendmail has all those features,
I can tell you that even when I first attend my first sendmail workshop,
approx. 27 years ago, I still would not know how to implement them
with sendmail.

> I were an MX administrator. Would I not want all the options/help
> I could get to defend myself against attack?

I still don't get the difference if sendmail would be a port/pkg.

Oh, btw, if sendmail can do all this, wouldn't it be useful to
have a suitable config that does all this right out of the box ?

Because, honestly, I would not know how to enable all those features...

> True. But if I'm selling a Server targeted OS. Don't I want to
> advocate server grade services?

But the distribution channel of the software for that service
(base or port) does not sound as the relevant factor for the
end-user, or does it ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Matthias Apitz]

El día lunes, diciembre 11, 2017 a las 11:26:44a. m. -0700, Warren Block 
escribió:

> > Warren, you have not got my point: Why specfying '-d ${USER}' is required 
> > in 
> > a per user file in its HOME?

The maildrop is started as the user 'foo' by a line in a file ~foo/.forward,
as you say:

maildrop -d foo

and this '-d foo' is IMHO completely superfluous, because the maildrop could do
by its own a getuid(2) and a user 'foo' will never run (and perhaps can
not run due to lack of permissions) something like '-d bla'.

Do you copy me?

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/   
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub


signature.asc
Description: PGP signature

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 08:39:02 -0800  said


On Mon, 11 Dec 2017 11:10:32 + "Matt Smith"  said

> On Dec 10 14:58, Chris H wrote:
>>OK I'm puzzled a bit. FreeBSD' motto has always been:
>>FreeBSD
>>The power to serve!
> >
>>but many of the proposed, and recent changes/removals end up more like:
>>FreeBSD
>>I's castrated!
> 
> The problem with software in the base is that it is *much* more 
> difficult to update to add new features or patch security issues. With a 
> port the software will be updated relatively quickly. And users can get 
> the benefits of that with a quick pkg upgrade. They might not update 
> their O/S for 6-12 months.
> 
> In my opinion any software which is accessible to the internet should be 
> patched and upgraded ASAP. It's for this reason that I've always 
> disabled things like OpenSSH/OpenSSL/ntpd etc in the base and used port 
> versions instead.

I applaud that attitude. I couldn't agree more. For that same reason, I
(not unlike you) have always excluded software that history has proven
to pose security risks ( WITHOUT_BIND=true ) for example. The same can also
*easily* be said of OpenSSL.


[ excessive "jag" removed. sorry ]


threat.
In closing, and more to the point regarding Sendmail; Sendmail has a nearly
impeccable security record in at the last decade. It provides a *secure*,
more powerful, and more flexible MX on the cheap. I see little reason to
consider it an attack vector. Which makes *security*, and it's related
maintenance a pretty poor argument, for it's removal.

--Chris

Let me attempt to make my point another way (and stay closer to topic).
A user is able to accomplish more from sendmail in base, than with any
other MX port in base alone.
Sendmail provides OOB:
block by topic/portion of topic
block forged MX
block dynamic host(s)
all with the addition of one stanza, and (in the case "topic") the
addition of TOPIC_FILE
it also provides for some other measures that trip up, or otherwise
thwart spammer tactics;
delay (E)HELO
connection THROTTLING. As well as the ability to utilize block
list services, offered by third parties, or your own personal block
list.
Many of the other MX software in the ports tree provide a subset of
the shortlist I mentioned above. But none of them offer them all.
Given that the biggest concern, both security-wise, as well
nuisance-wise from anyone managing an internet facing MX service is
SPAM, and related threats. Wouldn't one be best served, if they had
the most options available to defend against such threats?
FWIW in ~5 months only having (ever) having sendmail from base,
without the addition of any additional "plugins".
I was able to collect (and subsequently block)  ~9.9 million SPAM
sources. Not likely, but *actual* spam sources.
When I began life as a maintainer of ports. I was subsequently
required to subscribe to additional FreeBSD mailing lists, and
provide my/a email address along with the the ports I maintain.
As a result, my [that] address had a greater exposure to spammers.
In a short time, I found myself inundated with SPAM -- literally
*thousands* per day. My initial reaction was to curse the FreeBSD
ports/mailing-list management system, and those who were in charge.
But I decided against a knee-jerk reaction, and decided to give the
matter more thought, before making a decision. In the end, I decided
I wasn't going to allow myself to be a victim, but rather make the
whole matter a challenge, or puzzle that I would solve. In the end,
and with my current base version of sendmail, I now only receive
some 3-5 SPAM/week. That is a *remarkable* number, compared to my
initial experience, as the number of *actual* SPAM sources I've
been able to thwart. That 9.9 million number is not a *probable*
number, it's an actual figure, and in the end, I *always* get the
mail I want, and nearly *never* get the mail I don't. All with
sendmail from base, and without any external/third party services.
IMHO that makes a pretty strong argument for retaining Sendmail. If
I were an MX administrator. Would I not want all the options/help
I could get to defend myself against attack? This is the sort of
thing that makes FreeBSD the best choice for a Server Grade install.
It provides server grade applications in a Service oriented OS.

Yes. But if it's removed. Nothing stops you from installing it
from ports.

True. But if I'm selling a Server targeted OS. Don't I want to
advocate server grade services?

Thanks for listening -- I know it was long.

--Chris

> 
> -- 
> Matt



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to 

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> If you, as an administrator of a/your system(s), see no problem with
> (port) scanners, and take no action to thwart such activity. You are
> more than likely to encounter trouble(s) down the road.

Right, portscanning is bad, if not done in a transparent way,
so as sys-admin I have to reduce exposure.

But it's a valid tool, nevertheless.

> In short; I see them all as "black hats". Honestly. Can you *really*
> determine good intentions from bad intentions on an incoming port scan?

Yes. If it's done with full transparency, I don't mind scanning.

With transparency, I mean:
- reverse dns is set
- scan from the same IP all the time
- some point of contact for the scan (a website, email etc)
- if requested, the scanner delivers individual results to the scanned
- if requested, one can be excluded from the scan
- all the results are only used for 'above-the-waterline' work,
  like research or statistics
- scanner is willing to be audited
- [maybe some other rules...]

In fact, I've even organised such a project doing that for TLS:

https://github.com/TLS-Check/tls-check

I would not mind a registry at IANA for such transparent scan projects,
so that all the other ones can be traced and stopped.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> if the majority of people install their systems via packages, that makes for
> a fairly common FreeBSD base across all users.

Why would a system installed via packaged be more homogenous than
one installed as base, and updated via freebsd-update ? I don't
understand this -- can you elaborate ?

> In closing, and more to the point regarding Sendmail; Sendmail has a nearly
> impeccable security record in at the last decade. It provides a *secure*,
> more powerful, and more flexible MX on the cheap. I see little reason to
> consider it an attack vector. Which makes *security*, and it's related
> maintenance a pretty poor argument, for it's removal.

The argument is: The update process for base is more complex
than for packages, and we've come a long way to have a very
nice pkg-system, in general. The mid-term plan is thus to package base, too.

Packaging base means sensible packages have to be defined, and
sendmail suits a package very well.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Warren Block]

On Mon, 11 Dec 2017, Matthias Apitz wrote:

On Monday, 11 December 2017 04:56:04 CET, Warren Block  
wrote:

On Fri, 8 Dec 2017, Matthias Apitz wrote:

El día viernes, diciembre 08, 2017 a las 03:13:02p. m. -0700, Warren Block 
escribió:



Hmm, why -d ${USER} if this is already known who I am from the
~/.forward file location?


Because as a sysadmin, then you can copy it to another user without
having to edit it each time.


Hmm, and why the sysadmin has to put in each copy the '-d ${USER}' when
he/she puts the copy in the ~/.forward file of the USER?


Because it's a per-user setting?  I don't know for a fact, but that's how 
I'd do it: make the solution as general as possible.


Warren, you have not got my point: Why specfying '-d ${USER}' is required in 
a per user file in its HOME?


I guess I still don't understand.  I don't know if it's safe or good 
practice to assume $USER is set to the value of basename(~).

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 16:42:57 +0100 "Kurt Jaeger"  said


Hi!

> > On Sun, Dec 10, 2017 at 02:58:29PM -0800, Chris H wrote:
> > > OK I'm puzzled a bit. FreeBSD' motto has always been:
> > > FreeBSD
> > > The power to serve!
> > > 
> > > but many of the proposed, and recent changes/removals end up more like:

> > > FreeBSD
> > > I's castrated!

> > So, then we should add a web server into our base! Apache? NGINX? Both?
> > But then, what about PHP? MySQL? PostgreSQL? We want to serve websites,
> > after all! Let's talk about fileservers. Samba! I could go on...
> OK. That's simply an irrelevant argument. I never advocated for the
> *addition* of anything. Only against the *removal* of something most users
> have come to expect with the installation of FreeBSD.

The argument was made to show the general idea, not to nit-pick 8-}

As packaging base is also on the horizon, see

https://www.youtube.com/watch?v=Br6izhH5P1I

and

https://www.youtube.com/watch?v=v7px6ktoDAI

the debate will pop up in any case.

> > FreeBSD's power to serve slogan is about delivering the platform to
> > serve, not all possible server software. [...]

> In all fairness, that's just pure supposition. I would suggest that it is
> more probable that more users use Sendmail 1) because it came with the
> FreeBSD install, and 2) as such, makes it easier to implement.

Then it's time to start some research, if this hypothesis really holds.

Thanks for the links, and the thoughtful reply, Kurt!
In all fairness, your right. *actual* numbers *do* apply. :-)



I know that the folks at dovecot.fi did this in February for dovecot, see

openemailsurvey.org

It was made using shodan, maybe it's time to do the same for port 25
via shodan ?

LOL, showdan.io! Hah! I'm *more* than a little irritated by this sort of thing.
*Sure* it can provide some useful data. But the part that really irritates
me, is that anyone think it's OK to probe my ports w/o asking. It's akin
to saying; we initiated a study to determine how many people were using the
LG model XYZ refrigerator. In that study, we peered into all the windows
of as many houses, in as many neighborhoods as possible. But please, do not
feel violated. We made every effort to look away, if we encountered anyone
naked, or in an otherwise compromising situation. If you still find this
method too intrusive. You need only tell us so. Simply come, and try to
find the link to request exclusion. Err... what?!?!
If you, as an administrator of a/your system(s), see no problem with
(port) scanners, and take no action to thwart such activity. You are
more than likely to encounter trouble(s) down the road. Even those that
take preemptive action ahead of time, to close all unused ports. History
already *proves* this fact, time, and time again. :-)
pf(4) has dropped any/all communication from the showdan "project" *long*
ago for all the systems I'm responsible for, and along with all the myriad
of other "like" projects. They all have the policy backward; ask *before*
not *after*.
In short; I see them all as "black hats". Honestly. Can you *really*
determine good intentions from bad intentions on an incoming port scan?

Still. Your point is well taken, and your point is not on the top of your
head. ;-) ;-)
We really *do* need corroborating evidence. :-)

Thanks again, all the best to you, Kurt!

--Chris


--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 11:10:32 + "Matt Smith"  said


On Dec 10 14:58, Chris H wrote:
>OK I'm puzzled a bit. FreeBSD' motto has always been:
>FreeBSD
>The power to serve!
>
>but many of the proposed, and recent changes/removals end up more like:
>FreeBSD
>I's castrated!

The problem with software in the base is that it is *much* more 
difficult to update to add new features or patch security issues. With a 
port the software will be updated relatively quickly. And users can get 
the benefits of that with a quick pkg upgrade. They might not update 
their O/S for 6-12 months.


In my opinion any software which is accessible to the internet should be 
patched and upgraded ASAP. It's for this reason that I've always 
disabled things like OpenSSH/OpenSSL/ntpd etc in the base and used port 
versions instead.

I applaud that attitude. I couldn't agree more. For that same reason, I
(not unlike you) have always excluded software that history has proven
to pose security risks ( WITHOUT_BIND=true ) for example. The same can also
*easily* be said of OpenSSL.
However, the same argument can't be made for Sendmail. Further, if I take
your argument to it's logical end. I am left with only the kernel? At what
point is enough, enough? Is the new pkg(8) system simply an attempt to make
FreeBSD the new Debian? Where everything is installed via (a) pkg? I *dearly*
hope not. The thought makes me shudder. Not that I hate Debian/Linux. Just
that I *prefer* FreeBSD, or at least a *BSD. Taking that thought a bit further;
if the majority of people install their systems via packages, that makes for
a fairly common FreeBSD base across all users. Speaking (again) of security;
doesn't this lower the bar for entry for hacking the FreeBSD (user) base?
IOW if the majority installs their systems via packages, their systems will
all be *quite* similar. If I, an evil hacker, *knows* of an entry point/flaw/...
Then I can take down a *much* larger portion of FreeBSD users, than was
usually available to me. *This* point alone, seems the biggest argument
*against* "packaging everything". IOW because it's easier, does *not* make
it better. In the big scheme of things, it really makes it *lazier*. Or at
least makes it easier to be so. One *could* argue that it *encourages* it.
But I'm only speaking from decades of support/IT work. I *know* it's true,
and I'm *not* suggesting that FreeBSD is *advocating it*. Only that (my)
history, and experience proves that it is largely human nature to take the
least line of resistance. Which in this case says history will show that the
addition of a packaged system will raise number of people vulnerable to
threat.
In closing, and more to the point regarding Sendmail; Sendmail has a nearly
impeccable security record in at the last decade. It provides a *secure*,
more powerful, and more flexible MX on the cheap. I see little reason to
consider it an attack vector. Which makes *security*, and it's related
maintenance a pretty poor argument, for it's removal.

--Chris


--
Matt



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> > On Sun, Dec 10, 2017 at 02:58:29PM -0800, Chris H wrote:
> > > OK I'm puzzled a bit. FreeBSD' motto has always been:
> > > FreeBSD
> > > The power to serve!
> > > 
> > > but many of the proposed, and recent changes/removals end up more like:
> > > FreeBSD
> > > I's castrated!

> > So, then we should add a web server into our base! Apache? NGINX? Both?
> > But then, what about PHP? MySQL? PostgreSQL? We want to serve websites,
> > after all! Let's talk about fileservers. Samba! I could go on...
> OK. That's simply an irrelevant argument. I never advocated for the
> *addition* of anything. Only against the *removal* of something most users
> have come to expect with the installation of FreeBSD.

The argument was made to show the general idea, not to nit-pick 8-}

As packaging base is also on the horizon, see

https://www.youtube.com/watch?v=Br6izhH5P1I

and

https://www.youtube.com/watch?v=v7px6ktoDAI

the debate will pop up in any case.

> > FreeBSD's power to serve slogan is about delivering the platform to
> > serve, not all possible server software. [...]

> In all fairness, that's just pure supposition. I would suggest that it is
> more probable that more users use Sendmail 1) because it came with the
> FreeBSD install, and 2) as such, makes it easier to implement.

Then it's time to start some research, if this hypothesis really holds.

I know that the folks at dovecot.fi did this in February for dovecot, see

openemailsurvey.org

It was made using shodan, maybe it's time to do the same for port 25
via shodan ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Mon, 11 Dec 2017 11:49:06 +0100 "Lars Engels"  said


On Sun, Dec 10, 2017 at 02:58:29PM -0800, Chris H wrote:
> OK I'm puzzled a bit. FreeBSD' motto has always been:
> FreeBSD
> The power to serve!
> 
> but many of the proposed, and recent changes/removals end up more like:

> FreeBSD
> I's castrated!
> 


So, then we should add a web server into our base! Apache? NGINX? Both?
But then, what about PHP? MySQL? PostgreSQL? We want to serve websites,
after all! Let's talk about fileservers. Samba! I could go on...

OK. That's simply an irrelevant argument. I never advocated for the
*addition* of anything. Only against the *removal* of something most users
have come to expect with the installation of FreeBSD.



FreeBSD's power to serve slogan is about delivering the platform to
serve, not all possible server software. It just happens to have a mail
server in base because it always had, that's nothing that needs to be
kept forever. Probably 99% of the users don't use sendmail and the
remaining 1% know how to configure it, so installing them from ports is
a trivial thing for them.

In all fairness, that's just pure supposition. I would suggest that it is
more probable that more users use Sendmail 1) because it came with the
FreeBSD install, and 2) as such, makes it easier to implement. 3) Sendmail
is more robust/flexible OOB than than the other alternatives *without* the
addition of other software/plugins. 4) An administrator *needs* (at least)
daily logs, because... 5) Security is important, and Sendmail is cheap, and
(unlike the bind) has a reasonable security track record.

I would also argue that the most likely reason users don't like Sendmail,
is because they aren't comfortable with m4(1).

--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Michelle Sullivan]

Lars Engels wrote:

On Mon, Dec 11, 2017 at 09:09:39AM +1100, Dave Horsfall wrote:

On Sun, 10 Dec 2017, Adam Weinberger wrote:


DMA is a phenomenal program and is totally sufficient for a large
percentage of our user-base. I wasn’t aware of the lack of .forward
support, and I completely agree that that’s a very detrimental omission.

What about its spam filtering, such as /etc/mail/access and DNSBLs etc?


pkg install $some_spam_filtering_software_of_your_choice

That's not what belongs into base.



He didn't say spam filtering software.  Sendmail in base may be 
neutered, but it includes basic access controls and spam filtering 
rules.  Does the Dragonfly Mail Agent?


Personally I think if you remove Sendmail you should not replace it with 
something else... but then FreeBSD is not about what I want or what the 
users want anymore.


Michelle
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Lars Engels]

On Sun, Dec 10, 2017 at 02:58:29PM -0800, Chris H wrote:
> OK I'm puzzled a bit. FreeBSD' motto has always been:
> FreeBSD
> The power to serve!
> 
> but many of the proposed, and recent changes/removals end up more like:
> FreeBSD
> I's castrated!
> 

So, then we should add a web server into our base! Apache? NGINX? Both?
But then, what about PHP? MySQL? PostgreSQL? We want to serve websites,
after all! Let's talk about fileservers. Samba! I could go on...

FreeBSD's power to serve slogan is about delivering the platform to
serve, not all possible server software. It just happens to have a mail
server in base because it always had, that's nothing that needs to be
kept forever. Probably 99% of the users don't use sendmail and the
remaining 1% know how to configure it, so installing them from ports is
a trivial thing for them.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Lars Engels]

On Mon, Dec 11, 2017 at 09:09:39AM +1100, Dave Horsfall wrote:
> On Sun, 10 Dec 2017, Adam Weinberger wrote:
> 
> > DMA is a phenomenal program and is totally sufficient for a large 
> > percentage of our user-base. I wasn’t aware of the lack of .forward 
> > support, and I completely agree that that’s a very detrimental omission.
> 
> What about its spam filtering, such as /etc/mail/access and DNSBLs etc?
> 

pkg install $some_spam_filtering_software_of_your_choice

That's not what belongs into base.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Matthias Apitz]

On Monday, 11 December 2017 04:56:04 CET, Warren Block  
wrote:

On Fri, 8 Dec 2017, Matthias Apitz wrote:

El día viernes, diciembre 08, 2017 a las 03:13:02p. m. -0700, 
Warren Block escribió:



Hmm, why -d ${USER} if this is already known who I am from the
~/.forward file location?


Because as a sysadmin, then you can copy it to another user without
having to edit it each time.


Hmm, and why the sysadmin has to put in each copy the '-d ${USER}' when
he/she puts the copy in the ~/.forward file of the USER?


Because it's a per-user setting?  I don't know for a fact, but that's 
how I'd do it: make the solution as general as possible.


Warren, you have not got my point: Why specfying '-d ${USER}' is required 
in a per user file in its HOME?




--
Sent from my Ubuntu phone
http://www.unixarea.de/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Warren Block]

On Fri, 8 Dec 2017, Matthias Apitz wrote:


El día viernes, diciembre 08, 2017 a las 03:13:02p. m. -0700, Warren Block 
escribió:


Hmm, why -d ${USER} if this is already known who I am from the
~/.forward file location?


Because as a sysadmin, then you can copy it to another user without
having to edit it each time.


Hmm, and why the sysadmin has to put in each copy the '-d ${USER}' when
he/she puts the copy in the ~/.forward file of the USER?


Because it's a per-user setting?  I don't know for a fact, but that's 
how I'd do it: make the solution as general as possible.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

RE: Procmail Vulnerabilities check

[Thomas Mueller]

from Carmel NY:

> On Sunday, December 10, 2017 4:18 PM, RW wrote:
> > On Sun, 10 Dec 2017 10:10:30 -0800, Kevin Oberman wrote:
> > > Strongly agree! Support ofr some basics like .forward is really a
> > > requirement. It is used for too many "normal" mail operations
> > > including private dropmail or procmail setups as well as forwarding to
> > > a smartmail system.

> > This is actually an argument for taking sendmail out of the base system.
> > If you need to install dropmail or procmail as a package you might just as 
> > well
> > install an MTA in the same way.

> IMHO, I think that "postfix" should be the base MTA. It is far easier to 
> configure, it is rock solid
> and the Postfix forum and documentation are superb. Plus, Dovecot integrates 
> with it seamlessly.

NetBSD did that some time ago (made postfix the default MTA).

If sendmail is dropped from FreeBSD base, FreeBSD users who want sendmail can 
install from ports and get the real thing instead of a reduced version.

Yes, my /etc/src.conf includes the line

WITHOUT_SENDMAIL=yes

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Sun, 10 Dec 2017 14:54:54 -0700 "Adam Weinberger"  said


> On 8 Dec, 2017, at 20:11, Chris H  wrote:
>
> On Sat, 9 Dec 2017 02:59:28 +0100 "Kurt Jaeger"  said
>
>> Hi!
>> > > > First, there is movement afoot to remove sendmail from FreeBSD and  
>> > > > replace it with dma(1).
>> > Hmm. This does not come as good news to me. I've been working on an  
>> antispam

>> > system that targets the use of Sendmail,
>> If sendmail is available via ports, wouldn't that be enough ?
> Thanks for the reply, Kurt.
> Perhaps. Haven't tried it yet (means even more work). :(
> But hopefully.
> I thought all my work would have been more valuable, given that Sendmail
> was installed by default in FreeBSD. Disappointing, but perhaps still  
> doable.

> Time will tell.

Hi Chris,

I’d argue that if your work loses value if sendmail is removed from base  
(suggesting that users wouldn’t choose sendmail when given an option from 

ports), then that suggests that sendmail isn’t the right thing to include 

in base. Base should ship with the thing that we expect the majority of  
users to WANT to choose.


Clearly there are many users who still prefer sendmail. Your work still has 


value!

Thank you, Adam for the thoughtful reply.
I'm not arguing it's intrinsic value with Sendmail. But rather; I was
just indicating that it would be of more value to FreeBSD users, given
that that would *likely* be their MX, as Sendmail is installed so out
of the box. Meaning; Since FreeBSD has (largely) already set it up for
them, they're probably already using it, and that means more Sendmail
users *by default*. :-)

Thanks again, Adam.

--Chris


# Adam




___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Sun, 10 Dec 2017 14:49:02 -0700 "Adam Weinberger"  said

> On 10 Dec, 2017, at 10:11, Steve Kargl   
> wrote:

>
> On Sun, Dec 10, 2017 at 01:21:13PM +, Matthew Seaman wrote:
>> Hence the current sendmail in base is neither fish nor fowl: way
>> overpowered for almost all installations, but with significant
>> limitations for a machine providing a full-blown mail service.
>> Personally I agree with his reasoning: unless the primary function of
>> your FreeBSD machine is to be an MTA, you really don't need any more
>> capability than to either deliver to a local mailbox, or forward all
>> e-mails to a smart host.  Certainly you don't need anything capable of
>> receiving incoming e-mails.
>
> I disagree.  FreeBSd used to pride itself on being a complete operating
> system oout-of-the-box.  Lately, a smaller number of developers are
> moving FreeBSD to being a kernel with a bunch of add-on software.
>
> dma(1) does not support a .forward file and by extension vacation(1).
> Without .forward, then those of use who use procmail(1) (subject of
> this email thread) in .forward and by extension spamassisin are
> hosed.
>
> Chapter 27 of the FreeBSD Handbook would need to be rewritten before
> sendmail can be removed.  It is assumed that sendmail is installed
> with base.

Hi Steve,

I agree with you about the merits of FreeBSD providing a complete system  
out-of-the-box. But of all the mail servers out there, sendmail is the most 

archaic and arcane. Sendmail is used primarily by people who are intimately 

familiar with it over a long history, and simply isn’t a great choice for 

people getting into mail servers. I’d rather see sendmail installable  
through ports, and replaced in base with a better solution. Sendmail is too 

difficult to configure correctly; we should keep it trivial to install  
(i.e. ports) for those who prefer it, but it shouldn’t be our primary  
recommendation for users looking for a new MTA.


DMA is a phenomenal program and is totally sufficient for a large  
percentage of our user-base. I wasn’t aware of the lack of .forward  
support, and I completely agree that that’s a very detrimental omission.


# Adam

OK I'm puzzled a bit. FreeBSD' motto has always been:
FreeBSD
The power to serve!

but many of the proposed, and recent changes/removals end up more like:
FreeBSD
I's castrated!

IOW
Why the big push to eliminate perhaps it's biggest attributes. FreeBSD
has always been a *server* out-of-the-box. This should never change.
You need something other than a server? You can install almost every
other OS/distro. Let's also not forget, that if you need a FreeBSD
/desktop/ one need only look at the fork to accomplish just that
http://www.desktopbsd.net/
Want to produce a FreeBSD desktop from the FreeBSD source?
https://www.freebsd.org/doc/en/books/handbook/x11-wm.html
from the handbook. There's also much documentation on all the other
possibilities regarding more lightweight alternatives to the
applications installed in $BASE.

You don't want Sendmail installed by/as default? FreeBSD *already*
provides that option in src.conf(5):
WITHOUT_SENDMAIL=true
and a myriad of other possibilities -- including the addition of
things from ports(7)!
Please, let's not attempt to dilute FreeBSD' biggest strengths/
value anymore that has already been done. FreeBSD' strongest
attribute is it's being quite possibly, the best server installation
out-of-the-box -- certainly the closest POSIX server out-of-the-box.
Why remove it's best selling point/attribute?

--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Dave Horsfall]

On Sun, 10 Dec 2017, Adam Weinberger wrote:

DMA is a phenomenal program and is totally sufficient for a large 
percentage of our user-base. I wasn’t aware of the lack of .forward 
support, and I completely agree that that’s a very detrimental omission.


What about its spam filtering, such as /etc/mail/access and DNSBLs etc?

(I hope it's a coincidence that its name is also the same as the pro-spam 
Direct Marketing Association...)


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Adam Weinberger]

On 8 Dec, 2017, at 20:11, Chris H  wrote:

On Sat, 9 Dec 2017 02:59:28 +0100 "Kurt Jaeger"  said


Hi!
> > > First, there is movement afoot to remove sendmail from FreeBSD and  
> > > replace it with dma(1).
> Hmm. This does not come as good news to me. I've been working on an  
antispam

> system that targets the use of Sendmail,
If sendmail is available via ports, wouldn't that be enough ?

Thanks for the reply, Kurt.
Perhaps. Haven't tried it yet (means even more work). :(
But hopefully.
I thought all my work would have been more valuable, given that Sendmail
was installed by default in FreeBSD. Disappointing, but perhaps still  
doable.

Time will tell.


Hi Chris,

I’d argue that if your work loses value if sendmail is removed from base  
(suggesting that users wouldn’t choose sendmail when given an option from  
ports), then that suggests that sendmail isn’t the right thing to include  
in base. Base should ship with the thing that we expect the majority of  
users to WANT to choose.


Clearly there are many users who still prefer sendmail. Your work still has  
value!


# Adam


--
Adam Weinberger
ad...@adamw.org
http://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Adam Weinberger]

On 10 Dec, 2017, at 10:11, Steve Kargl   
wrote:


On Sun, Dec 10, 2017 at 01:21:13PM +, Matthew Seaman wrote:

Hence the current sendmail in base is neither fish nor fowl: way
overpowered for almost all installations, but with significant
limitations for a machine providing a full-blown mail service.
Personally I agree with his reasoning: unless the primary function of
your FreeBSD machine is to be an MTA, you really don't need any more
capability than to either deliver to a local mailbox, or forward all
e-mails to a smart host.  Certainly you don't need anything capable of
receiving incoming e-mails.


I disagree.  FreeBSd used to pride itself on being a complete operating
system oout-of-the-box.  Lately, a smaller number of developers are
moving FreeBSD to being a kernel with a bunch of add-on software.

dma(1) does not support a .forward file and by extension vacation(1).
Without .forward, then those of use who use procmail(1) (subject of
this email thread) in .forward and by extension spamassisin are
hosed.

Chapter 27 of the FreeBSD Handbook would need to be rewritten before
sendmail can be removed.  It is assumed that sendmail is installed
with base.


Hi Steve,

I agree with you about the merits of FreeBSD providing a complete system  
out-of-the-box. But of all the mail servers out there, sendmail is the most  
archaic and arcane. Sendmail is used primarily by people who are intimately  
familiar with it over a long history, and simply isn’t a great choice for  
people getting into mail servers. I’d rather see sendmail installable  
through ports, and replaced in base with a better solution. Sendmail is too  
difficult to configure correctly; we should keep it trivial to install  
(i.e. ports) for those who prefer it, but it shouldn’t be our primary  
recommendation for users looking for a new MTA.


DMA is a phenomenal program and is totally sufficient for a large  
percentage of our user-base. I wasn’t aware of the lack of .forward  
support, and I completely agree that that’s a very detrimental omission.


# Adam


--
Adam Weinberger
ad...@adamw.org
http://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

RE: Procmail Vulnerabilities check

[Carmel NY]

On Sunday, December 10, 2017 4:18 PM, RW wrote:
> On Sun, 10 Dec 2017 10:10:30 -0800, Kevin Oberman wrote:
> > Strongly agree! Support ofr some basics like .forward is really a
> > requirement. It is used for too many "normal" mail operations
> > including private dropmail or procmail setups as well as forwarding to
> > a smartmail system.
> 
> This is actually an argument for taking sendmail out of the base system.
> If you need to install dropmail or procmail as a package you might just as 
> well
> install an MTA in the same way.

IMHO, I think that "postfix" should be the base MTA. It is far easier to 
configure, it is rock solid
and the Postfix forum and documentation are superb. Plus, Dovecot integrates 
with it seamlessly.

-- 
Carmel


pgpleBOSqAB08.pgp
Description: PGP signature

Re: Procmail Vulnerabilities check

[RW via freebsd-ports]

On Sun, 10 Dec 2017 10:10:30 -0800
Kevin Oberman wrote:


> Strongly agree! Support ofr some basics like .forward is really a
> requirement. It is used for too many "normal" mail operations
> including private dropmail or procmail setups as well as forwarding
> to a smartmail system.

This is actually an argument for taking sendmail out of the base system.
If you need to install dropmail or procmail as a package you might
just as well install an MTA in the same way. 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kevin Oberman]

On Sun, Dec 10, 2017 at 9:11 AM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Sun, Dec 10, 2017 at 01:21:13PM +, Matthew Seaman wrote:
> >
> > Hence the current sendmail in base is neither fish nor fowl: way
> > overpowered for almost all installations, but with significant
> > limitations for a machine providing a full-blown mail service.
> > Personally I agree with his reasoning: unless the primary function of
> > your FreeBSD machine is to be an MTA, you really don't need any more
> > capability than to either deliver to a local mailbox, or forward all
> > e-mails to a smart host.  Certainly you don't need anything capable of
> > receiving incoming e-mails.
> >
>
> I disagree.  FreeBSd used to pride itself on being a complete operating
> system oout-of-the-box.  Lately, a smaller number of developers are
> moving FreeBSD to being a kernel with a bunch of add-on software.
>
> dma(1) does not support a .forward file and by extension vacation(1).
> Without .forward, then those of use who use procmail(1) (subject of
> this email thread) in .forward and by extension spamassisin are
> hosed.
>
> Chapter 27 of the FreeBSD Handbook would need to be rewritten before
> sendmail can be removed.  It is assumed that sendmail is installed
> with base.
>
> --
> Steve
>

Strongly agree! Support ofr some basics like .forward is really a
requirement. It is used for too many "normal" mail operations including
private dropmail or procmail setups as well as forwarding to a smartmail
system.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Steve Kargl]

On Sun, Dec 10, 2017 at 01:21:13PM +, Matthew Seaman wrote:
> 
> Hence the current sendmail in base is neither fish nor fowl: way
> overpowered for almost all installations, but with significant
> limitations for a machine providing a full-blown mail service.
> Personally I agree with his reasoning: unless the primary function of
> your FreeBSD machine is to be an MTA, you really don't need any more
> capability than to either deliver to a local mailbox, or forward all
> e-mails to a smart host.  Certainly you don't need anything capable of
> receiving incoming e-mails.
> 

I disagree.  FreeBSd used to pride itself on being a complete operating
system oout-of-the-box.  Lately, a smaller number of developers are 
moving FreeBSD to being a kernel with a bunch of add-on software.

dma(1) does not support a .forward file and by extension vacation(1).
Without .forward, then those of use who use procmail(1) (subject of
this email thread) in .forward and by extension spamassisin are 
hosed.

Chapter 27 of the FreeBSD Handbook would need to be rewritten before
sendmail can be removed.  It is assumed that sendmail is installed
with base.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Matthew Seaman]

On 09/12/2017 04:12, Dave Horsfall wrote:
> On Fri, 8 Dec 2017, Steve Kargl wrote:
> 
>> https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html
>>
> 
> Well, I saw no reason to subscribe to freebsd-arch (I'm on enough lists
> as it is)...  Are there any other lists that we should be following?
> 
> I guess a suit and tie will be required soon :-(
> 
> I'm bemused by Bapt's remark that "it does not support anything an
> entreprised [sic] grade mta setup would require: ldap support for
> example"; funny, as I had it working just fine with OpenLDAP with
> hundreds of users spread over many offices in my last job, with no
> trouble at all; there's even a schema for it, FFS:
> 
>     aneurin% locate -i sendmail.schema
>     /usr/share/sendmail/cf/sendmail.schema
> 
> with all the right gear in it:
> 
>     # OID arcs for Sendmail
>     # enterprise:   1.3.6.1.4.1
>     # sendmail: enterprise.6152
> 
> WTF?  Sure as hell looks like Sendmail supports LDAP to me...
> 

Bapt's point here is that the version of sendmail in base is quite
limited since, for instance, it is not compiled with ldap client support
or various other optional features.  On the other hand, the version of
sendmail in ports can be compiled with all the different bells and
whistles enabled.

If your machine is configured as a smarthost MTA, then generally you'll
want to install one of the more fully capable MTA packages from ports --
sendmail, postfix, exim etc.

For most other setups, a machine does not need to do anything more with
e-mail than deliver locally generated mails (from cron or whatever)
either to a local mailbox or to a smarthost.

Hence the current sendmail in base is neither fish nor fowl: way
overpowered for almost all installations, but with significant
limitations for a machine providing a full-blown mail service.
Personally I agree with his reasoning: unless the primary function of
your FreeBSD machine is to be an MTA, you really don't need any more
capability than to either deliver to a local mailbox, or forward all
e-mails to a smart host.  Certainly you don't need anything capable of
receiving incoming e-mails.

Cheers,

Matthew






signature.asc
Description: OpenPGP digital signature

Re: Procmail Vulnerabilities check

[George Mitchell]

On 12/09/17 00:42, Chris H wrote:
> [...] So I'd like to respectfully request that Sendmail stays.
> All those in favor, say aye!
> [...]

  A   Y   Y E !
 A A   Y Y  E !
A   Y   EEE   !
A   A   Y   E
A   A   Y   E !  -- George



signature.asc
Description: OpenPGP digital signature

Re: Procmail Vulnerabilities check

[Michelle Sullivan]

Chris H wrote:

P.S. Please try to keep it civil.

Ok..

.

Michelle
:)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Sat, 9 Dec 2017 15:12:12 +1100 (EST) "Dave Horsfall"  said


On Fri, 8 Dec 2017, Steve Kargl wrote:

> https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html

Well, I saw no reason to subscribe to freebsd-arch (I'm on enough lists as 
it is)...  Are there any other lists that we should be following?


I guess a suit and tie will be required soon :-(

I'm bemused by Bapt's remark that "it does not support anything an 
entreprised [sic] grade mta setup would require: ldap support for 
example"; funny, as I had it working just fine with OpenLDAP with hundreds 
of users spread over many offices in my last job, with no trouble at all; 
there's even a schema for it, FFS:


aneurin% locate -i sendmail.schema
/usr/share/sendmail/cf/sendmail.schema

with all the right gear in it:

# OID arcs for Sendmail
# enterprise:   1.3.6.1.4.1
# sendmail: enterprise.6152

WTF?  Sure as hell looks like Sendmail supports LDAP to me...


Agreed!
OK I don't have a copy of HEAD handy to search. But a look at the web
copy of the svn repo shows it's still there. The logs show no impending
doom. So I'd like to respectfully request that Sendmail stays.
All those in favor, say aye!

--Chris
P.S. Please try to keep it civil. :-)


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Dave Horsfall]

On Fri, 8 Dec 2017, Steve Kargl wrote:


https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html


Well, I saw no reason to subscribe to freebsd-arch (I'm on enough lists as 
it is)...  Are there any other lists that we should be following?


I guess a suit and tie will be required soon :-(

I'm bemused by Bapt's remark that "it does not support anything an 
entreprised [sic] grade mta setup would require: ldap support for 
example"; funny, as I had it working just fine with OpenLDAP with hundreds 
of users spread over many offices in my last job, with no trouble at all; 
there's even a schema for it, FFS:


aneurin% locate -i sendmail.schema
/usr/share/sendmail/cf/sendmail.schema

with all the right gear in it:

# OID arcs for Sendmail
# enterprise:   1.3.6.1.4.1
# sendmail: enterprise.6152

WTF?  Sure as hell looks like Sendmail supports LDAP to me...

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Sat, 9 Dec 2017 02:59:28 +0100 "Kurt Jaeger"  said


Hi!

> > > First, there is movement afoot to remove sendmail from FreeBSD and 
> > > replace it with dma(1).


> Hmm. This does not come as good news to me. I've been working on an antispam
> system that targets the use of Sendmail,

If sendmail is available via ports, wouldn't that be enough ?

Thanks for the reply, Kurt.
Perhaps. Haven't tried it yet (means even more work). :(
But hopefully.
I thought all my work would have been more valuable, given that Sendmail
was installed by default in FreeBSD. Disappointing, but perhaps still doable.
Time will tell.

Thanks again, Kurt!


--
p...@opsec.eu+49 171 3101372 3 years to go
!



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Fri, 8 Dec 2017 17:25:22 -0800  said


On Sat, Dec 09, 2017 at 10:16:54AM +1100, Dave Horsfall wrote:
> On Fri, 8 Dec 2017, Steve Kargl wrote:
> 
> > First, there is movement afoot to remove sendmail from FreeBSD and 
> > replace it with dma(1).
> 
> There is?  Is there anything else that they're going to spring on us?
> 


https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html

Thanks for the link, Steve.
I only wish I hadn't missed/overlooked it, when it was announced. Grrr...

I don't suppose that the (WITH|OUT)_SENDMAIL option will/can still be honored?



FreeBSD use to pride itself on being a complete (unix-like)
operating system out-of-box.

--
Steve


--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Dave Horsfall]

On Sat, 9 Dec 2017, Kurt Jaeger wrote:

[ On removing Sendmail from FreeBSD ]


If sendmail is available via ports, wouldn't that be enough ?


It better be in ports (but don't look at me; I have my hands full with my 
Mac & iPad with possibly an iPhone and an Android thrown in, and two 
Penguins); I've spent about 30 years with Sendmail and I ain't changing (I 
looked at Postfix but didn't like it)...


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> > > First, there is movement afoot to remove sendmail from FreeBSD and 
> > > replace it with dma(1).

> Hmm. This does not come as good news to me. I've been working on an antispam
> system that targets the use of Sendmail,

If sendmail is available via ports, wouldn't that be enough ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Steve Kargl]

On Sat, Dec 09, 2017 at 10:16:54AM +1100, Dave Horsfall wrote:
> On Fri, 8 Dec 2017, Steve Kargl wrote:
> 
> > First, there is movement afoot to remove sendmail from FreeBSD and 
> > replace it with dma(1).
> 
> There is?  Is there anything else that they're going to spring on us?
> 

https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html

FreeBSD use to pride itself on being a complete (unix-like)
operating system out-of-box.  

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Chris H]

On Sat, 9 Dec 2017 10:16:54 +1100 (EST) "Dave Horsfall"  said


On Fri, 8 Dec 2017, Steve Kargl wrote:

> First, there is movement afoot to remove sendmail from FreeBSD and 
> replace it with dma(1).


There is?  Is there anything else that they're going to spring on us?

(I'm still annoyed that they removed "jive" because it upset someone's 
delicate sensibilities.)

Hmm. This does not come as good news to me. I've been working on an antispam
system that targets the use of Sendmail, for about a year (not counting the
untold hours spent tuning it over the years). Sure, many aren't comfortable
with the m4(1) macros. But c'mon. Please don't.
As to these backstage removal discussions; is it remotely possible that
those of whom continue to use, and contribute to *BSD after all these years
might be included in these discussions?
I understand the tantrums, and bikeshedding that's occurred in the past,
revolving around these types of discussion(s). But may I humbly suggest that it
may be largely in part, because these decisions were simply *sprung* on
everyone? Which is bound to insight some degree of panic in some, or perhaps
even many.

--Chris


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Dave Horsfall]

On Fri, 8 Dec 2017, Steve Kargl wrote:

First, there is movement afoot to remove sendmail from FreeBSD and 
replace it with dma(1).


There is?  Is there anything else that they're going to spring on us?

(I'm still annoyed that they removed "jive" because it upset someone's 
delicate sensibilities.)


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Matthias Apitz]

El día viernes, diciembre 08, 2017 a las 03:13:02p. m. -0700, Warren Block 
escribió:

> > Hmm, why -d ${USER} if this is already known who I am from the
> > ~/.forward file location?
> 
> Because as a sysadmin, then you can copy it to another user without 
> having to edit it each time.

Hmm, and why the sysadmin has to put in each copy the '-d ${USER}' when
he/she puts the copy in the ~/.forward file of the USER?

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/   
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub


signature.asc
Description: PGP signature

Re: Procmail Vulnerabilities check

[Warren Block]

On Fri, 8 Dec 2017, Matthias Apitz wrote:


El día viernes, diciembre 08, 2017 a las 11:19:03a. m. -0700, Warren Block 
escribió:


I do, and invoke procmail from a .forward file.

%  cat ~/.forward
"|exec /usr/local/bin/procmail -f-"

Do you know if maildrop can be used in a similar way?  I
suppose I have some reading to do.


I have not used a .forward file in a long time, but certainly it can be
done... found this in http://www.postfix.org/MAILDROP_README.html:


I do use ~/.forward and ~/.procmailrc for many years and they do just
fine (I filter some mail local to special folders and all the rest goes
to spamc of SpanAssassin, and as result if the decision of the latter
to my mbox or to dustbin); as I read the PR, this chain is not affected
by the bug, and I will just continue doing so;


/home/you/.forward:
 "|/path/to/maildrop -d ${USER}"


Hmm, why -d ${USER} if this is already known who I am from the
~/.forward file location?


Because as a sysadmin, then you can copy it to another user without 
having to edit it each time.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Steve Kargl]

On Fri, Dec 08, 2017 at 11:19:03AM -0700, Warren Block wrote:
> On Fri, 8 Dec 2017, Steve Kargl wrote:
> > On Fri, Dec 08, 2017 at 09:58:55AM -0700, Warren Block wrote:
> >>
> >> procmail is ancient, and has had known quality issues for much of the
> >> time.  Consider maildrop as a more powerful and more maintained
> >> replacement that is pretty easy to implement:
> >>
> >> http://www.wonkity.com/~wblock/docs/html/maildrop.html
> >
> > Warren,
> >
> > Thanks for the pointer to another of your excellent short tutorials.
> >
> > I note that you discuss sendmail's /etc/mail/hostname.mc
> > file and how to reset local_procmail.  First, there is
> > movement afoot to remove sendmail from FreeBSD and replace
> > it with dma(1).  Second, a number of people probably do as
> > I do, and invoke procmail from a .forward file.
> >
> > %  cat ~/.forward
> > "|exec /usr/local/bin/procmail -f-"
> >
> > Do you know if maildrop can be used in a similar way?  I
> > suppose I have some reading to do.
> 
> I have not used a .forward file in a long time, but certainly it can be 
> done... found this in http://www.postfix.org/MAILDROP_README.html:
> 
> /home/you/.forward:
>  "|/path/to/maildrop -d ${USER}"
> 
> 
> My impression of maildrop is that it has a superset of procmail's 
> abilities, but with easier syntax and easier but more powerful PCRE 
> regexes.

Thanks.  I'll start to migrate away from procmail, which
incidentally filed your reply in my -junkfilter folder. :-)

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Matthias Apitz]

El día viernes, diciembre 08, 2017 a las 11:19:03a. m. -0700, Warren Block 
escribió:

> > I do, and invoke procmail from a .forward file.
> >
> > %  cat ~/.forward
> > "|exec /usr/local/bin/procmail -f-"
> >
> > Do you know if maildrop can be used in a similar way?  I
> > suppose I have some reading to do.
> 
> I have not used a .forward file in a long time, but certainly it can be 
> done... found this in http://www.postfix.org/MAILDROP_README.html:

I do use ~/.forward and ~/.procmailrc for many years and they do just
fine (I filter some mail local to special folders and all the rest goes
to spamc of SpanAssassin, and as result if the decision of the latter
to my mbox or to dustbin); as I read the PR, this chain is not affected
by the bug, and I will just continue doing so;

> /home/you/.forward:
>  "|/path/to/maildrop -d ${USER}"

Hmm, why -d ${USER} if this is already known who I am from the
~/.forward file location?

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/   
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub


signature.asc
Description: PGP signature

Re: Procmail Vulnerabilities check

[Warren Block]

On Fri, 8 Dec 2017, Steve Kargl wrote:


On Fri, Dec 08, 2017 at 09:58:55AM -0700, Warren Block wrote:

On Fri, 8 Dec 2017, Jos Chrispijn wrote:


A little concernedthat I got no response to this.
Is Procmail dead for most of you guys(ducking)


procmail is ancient, and has had known quality issues for much of the
time.  Consider maildrop as a more powerful and more maintained
replacement that is pretty easy to implement:

http://www.wonkity.com/~wblock/docs/html/maildrop.html


Warren,

Thanks for the pointer to another of your excellent short tutorials.

I note that you discuss sendmail's /etc/mail/hostname.mc
file and how to reset local_procmail.  First, there is
movement afoot to remove sendmail from FreeBSD and replace
it with dma(1).  Second, a number of people probably do as
I do, and invoke procmail from a .forward file.

%  cat ~/.forward
"|exec /usr/local/bin/procmail -f-"

Do you know if maildrop can be used in a similar way?  I
suppose I have some reading to do.


I have not used a .forward file in a long time, but certainly it can be 
done... found this in http://www.postfix.org/MAILDROP_README.html:


/home/you/.forward:
"|/path/to/maildrop -d ${USER}"


My impression of maildrop is that it has a superset of procmail's 
abilities, but with easier syntax and easier but more powerful PCRE 
regexes.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Kurt Jaeger]

Hi!

> A little concerned that I got no response to this.
> Is Procmail dead for most of you guys(ducking)

We'll work the patch in, it just takes a little time 8-(

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Steve Kargl]

On Fri, Dec 08, 2017 at 09:58:55AM -0700, Warren Block wrote:
> On Fri, 8 Dec 2017, Jos Chrispijn wrote:
> 
> > A little concernedthat I got no response to this.
> > Is Procmail dead for most of you guys(ducking)
> 
> procmail is ancient, and has had known quality issues for much of the 
> time.  Consider maildrop as a more powerful and more maintained 
> replacement that is pretty easy to implement:
> 
> http://www.wonkity.com/~wblock/docs/html/maildrop.html

Warren,

Thanks for the pointer to another of your excellent short tutorials.

I note that you discuss sendmail's /etc/mail/hostname.mc
file and how to reset local_procmail.  First, there is 
movement afoot to remove sendmail from FreeBSD and replace
it with dma(1).  Second, a number of people probably do as
I do, and invoke procmail from a .forward file.

%  cat ~/.forward
"|exec /usr/local/bin/procmail -f-"

Do you know if maildrop can be used in a similar way?  I
suppose I have some reading to do.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Warren Block]

On Fri, 8 Dec 2017, Jos Chrispijn wrote:


A little concernedthat I got no response to this.
Is Procmail dead for most of you guys(ducking)


procmail is ancient, and has had known quality issues for much of the 
time.  Consider maildrop as a more powerful and more maintained 
replacement that is pretty easy to implement:


http://www.wonkity.com/~wblock/docs/html/maildrop.html
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Jos Chrispijn]

Nick,

Op 8-12-2017 om 17:32 schreef N.J. Mann:

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223777
specifically the patch in "Comment 2".  I have been using this
patch for a few days without problems.

Sadly the vulnerability check still fails.

Unfortunatly I am neither that of a programmer 
./Jos
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[N.J. Mann]

Hi,

On Friday, December 08, 2017 17:12:45 +0100 Jos Chrispijn 
 wrote:
> A little concernedthat I got no response to this.
> Is Procmail dead for most of you guys(ducking)

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223777
specifically the patch in "Comment 2".  I have been using this
patch for a few days without problems.

Sadly the vulnerability check still fails.


Cheers,
   Nick.
-- 

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Jos Chrispijn]

A little concernedthat I got no response to this.
Is Procmail dead for most of you guys(ducking)

Best regards,
Jos Chrispijn


Op 24-11-2017 om 13:32 schreef Jos Chrispijn:

Dear sunpoet,

Noticed this week following issue on procmail.

Vulnerabilities check

vulnxml file up-to-date
procmail-3.22_9 is vulnerable:
procmail -- Heap-based buffer overflow
CVE: CVE-2017-16844
WWW: 
https://vuxml.FreeBSD.org/freebsd/288f7cee-ced6-11e7-8ae9-0050569f0b83.html


Could you please send out a port update on this?

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Adam Weinberger]

> On 26 Nov, 2017, at 6:25, andrew clarke  wrote:
> 
> On Sat 2017-11-25 22:20:13 UTC-0500, Kevin P. Neal (k...@neutralgood.org) 
> wrote:
> 
>> Is that the consensus to replace use of procmail with maildrop?
>> 
>> A little googling makes it look like maildrop has the easy integration
>> with sendmail just like procmail. But is maildrop going to be around for
>> the next, oh, 20 years like procmail was?
> 
> maildrop began circa 1999 and is part of the Courier Mail Server
> software. procmail began circa 1990. Arguably both are due for a
> modern replacement, although at least maildrop does not suffer from
> vulnerabilities, afaik.

Sieve (ex. dovecot-pigeonhole) is the modern replacement.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[andrew clarke]

On Sat 2017-11-25 22:20:13 UTC-0500, Kevin P. Neal (k...@neutralgood.org) wrote:

> Is that the consensus to replace use of procmail with maildrop?
> 
> A little googling makes it look like maildrop has the easy integration
> with sendmail just like procmail. But is maildrop going to be around for
> the next, oh, 20 years like procmail was?

maildrop began circa 1999 and is part of the Courier Mail Server
software. procmail began circa 1990. Arguably both are due for a
modern replacement, although at least maildrop does not suffer from
vulnerabilities, afaik.

I migrated from procmail to maildrop a few years ago. My only real
gripe with it is that it doesn't create Maildir subdirectories
automatically, so you have to call 'maildirmake' from within each
filter rule (but only if the subdirectory doesn't already exist!)
making each maildroprc filter more complicated than necessary.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Andrea Venturoli]

On 11/25/17 17:59, Roger Marquis wrote:

Jos Chrispijn wrote:

Dear sunpoet,
Noticed this week following issue on procmail.
...
procmail -- Heap-based buffer overflow
https://vuxml.FreeBSD.org/freebsd/288f7cee-ced6-11e7-8ae9-0050569f0b83.html 



Whether mail/procmail is patched or deprecated standard practice has
been to upgrade to mailmaildrop for some years now.  Procmail source is
difficult to read at best, has been unmaintained for a long time and
mailmaildrop is a better tool for this job in almost every way (except
perhaps for macros like TO).


Unfortunately there are a few ports (8 or 9 it seems) that depend on 
procmail: I don't know how easy would be to move them to a different 
software.


I, for one, am not using procmail directly, but i use security/logcheck.

Just my 2c.

 bye
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[Roger Marquis]

Jos Chrispijn wrote:

Dear sunpoet,
Noticed this week following issue on procmail.
...
procmail -- Heap-based buffer overflow
https://vuxml.FreeBSD.org/freebsd/288f7cee-ced6-11e7-8ae9-0050569f0b83.html


Whether mail/procmail is patched or deprecated standard practice has
been to upgrade to mailmaildrop for some years now.  Procmail source is
difficult to read at best, has been unmaintained for a long time and
mailmaildrop is a better tool for this job in almost every way (except
perhaps for macros like TO).

Roger
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"