Quick question about this error I saw in the logs just now. There
is a note about it on Ralf's page [
http://www.arschkrebs.de/postfix/postfix_unknown.shtml ], but I am
trying to work out if its a problem or not caused by my postfix
implementation. The server really has no load. Its idle. After the
connect from unknown [unknown], mail reception continued as usual.
One change was made to-day, and was the activation of dkim-filter for
before and after queue processing, although the dkim-filter has been
running fine for the past 5 hours.
I would like to know whether the problem is my end or its a client being
naughty.
Best wishes, S.
Feb 2 17:09:28 logout postfix/smtpd[1599]: connect from unknown[unknown]
Feb 2 17:09:28 logout postfix/smtpd[1599]: lost connection after
CONNECT from unknown[unknown]
Feb 2 17:09:28 logout postfix/smtpd[1599]: disconnect from unknown[unknown]
Feb 2 17:09:51 logout postfix/smtpd[1599]: warning: 190.51.205.122:
hostname 190-51-205-122.speedy.com.ar verification failed: No address
associated with hostname
Feb 2 17:09:51 logout postfix/smtpd[1599]: connect from
unknown[190.51.205.122]
Feb 2 17:09:51 logout postfix/smtpd[1599]: lost connection after
CONNECT from unknown[190.51.205.122]
Feb 2 17:09:51 logout postfix/smtpd[1599]: disconnect from
unknown[190.51.205.122]
Feb 2 17:09:52 logout postfix/smtpd[1599]: warning: 190.51.205.122:
hostname 190-51-205-122.speedy.com.ar verification failed: No address
associated with hostname
Feb 2 17:09:52 logout postfix/smtpd[1599]: connect from
unknown[190.51.205.122]
Feb 2 17:09:52 logout postfix/smtpd[1599]: lost connection after
CONNECT from unknown[190.51.205.122]
Feb 2 17:09:52 logout postfix/smtpd[1599]: disconnect from
unknown[190.51.205.122]
Feb 2 17:13:12 logout postfix/anvil[1555]: statistics: max connection
rate 2/60s for (smtp:190.51.205.122) at Feb 2 17:09:52
Feb 2 17:13:12 logout postfix/anvil[1555]: statistics: max connection
count 1 for (smtp:64.74.157.82) at Feb 2 17:04:50
Feb 2 17:13:12 logout postfix/anvil[1555]: statistics: max cache size 3
at Feb 2 17:09:51
The client disconnected before Postfix could ask the KERNEL for
the client IP address. Either your server is too slow or the client
is too impatient.
> Feb 2 17:09:52 logout postfix/smtpd[1599]: connect from
> unknown[190.51.205.122]
> Feb 2 17:09:52 logout postfix/smtpd[1599]: lost connection after
> CONNECT from unknown[190.51.205.122]
The client disconnected before Postfix could send the SMTP server
greeting. Either your server is too slow or the client is too
impatient.
Wietse
> The smtpd has a 'sleep 3' at the start of it. Might this have been the
> cause? If so, then it served the purpose.
>
> smtpd_recipient_restrictions = sleep 3,
> permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,
> reject_non_fqdn_sender, reject_rbl_client
> hostkarma.junkemailfilter.com=127.0.0.2, reject_rbl_client zen.spamhaus.org
Unconditional "sleep <n>" applied even to servers that repeatedly pass
the test damages email infrastructure (by forcing legitimate servers
to expand substantially more resources, and delaying their email to
other destinations). Please don't do this. Consider upgrading to Postfix
2.8 and deploying postscreen(8) which remembers which servers pass the
test.
--
Viktor.
I can attest to the awesomeness of Stan's pcre file. I run it on all 5
of our Postfix servers, and it catches a LOT of stuff. From my logs,
what it seems to do best is block zombie mailers on dynamic IPs.
And I updated to your latest version today, Stan. Thanks :)
SteveJ
[snip]
Its a good idea, but this would limit a user from using a server on his residential ADSL from being an Email server, and force them to use their ISPs relay.I can attest to the awesomeness of Stan's pcre file. I run it on all 5 of our Postfix servers, and it catches a LOT of stuff. From my logs, what it seems to do best is block zombie mailers on dynamic IPs. And I updated to your latest version today, Stan. Thanks :) SteveJ
Else they might have to upgrade to a business package or spend more money for a static IP address
that they can amend the reverse lookup record for.
Pros and cons.No.
True. Some of the matches don't reject, but prepend this header:
X-GenericStaticHELO
What is this header used for?
> Jeroen Geilman put forth on 2/2/2011 2:56 PM:
>
> > Debian won't have 2.8 in stable until at least 2013, although you
> > may be able to get it as a backport later this year:
> >
> > http://packages.debian.org/search?keywords=postfix
> >
> > They lag behind something awful.
>
> You're smoke'n crack. ;) 2.7.1 was Wietse's latest stable when
> Debian froze the testing code base in prep for the release, which
> should occur within a month or so. Historically Debian has suffered
> from many stale packages, no argument there. But now that the
> backports project is an official part of Debian, this situation has
> become much better. BTW, I'm running backport 2.7.1. How is that
> lagging behind WRT to a distro package? Wietse just released 2.8 as
> stable a few weeks ago. Do you expect distro maintainers to have
> packages ready the next day? ;)
FreeBSD had the 2.8 release in its ports system a few days after it was
officially released. The 2.9(beta) release will be released into the
ports system shortly. The original 2.8(beta) was available almost
from its inception. The speed with which a package is made available to
a system is directly proportionate to the amount of time and effort a
maintainer wished to invest.
> CentOS 5.5, their latest, ships with Postfix 2.3.3, which hasn't been
> supported by Wietse for quite some time. A new install of CentOS 5.5
> gives you an officially unsupported Postfix, thought I'm sure CentOS
> will support it.
>
> Now _that_ is "lagging behind something awful".
CentOS's support for current software is an abomination. I wonder why
anyone takes it seriously.
--
Jerry ✌
postfi...@seibercom.net
_____________________________________________________________________
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
1 + 1 = 3, for large values of 1.
> On 02/02/2011 11:54 PM, Steve Jenkins wrote:
> > On Wed, Feb 2, 2011 at 2:33 PM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
> >> In the mean time, maybe give this a go. 1600+ expressions matching rDNS
> >> patterns of many millions of broadband IPs worldwide that shouldn't be sending
> >> direct SMTP. Catches quite a bit that PBL/CBL/SORBS-DYNA/etc don't and with
> >> less delay, reduced load on dnsbl servers and your own network. Potential FPs
> >> will be SOHO and "Linux weenie" MTAs on consumer IPs. Usage instructions are
> >> comments at the top of the file. Insert the restriction above/before any
> >> greylisting daemons in main.cf, obviously. Some on this list and many on the
> >> Dovecot list can testify to its effectiveness.
> >>
> >> http://www.hardwarefreak.com/fqrdns.pcre
> > I can attest to the awesomeness of Stan's pcre file. I run it on all 5
> > of our Postfix servers, and it catches a LOT of stuff. From my logs,
> > what it seems to do best is block zombie mailers on dynamic IPs.
> >
> > And I updated to your latest version today, Stan. Thanks :)
> >
> > SteveJ
> Its a good idea, but this would limit a user from using a server on his
> residential ADSL from being an Email server, and force them to use their
> ISPs relay. Else they might have to upgrade to a business package or
> spend more money for a static IP address that they can amend the reverse
> lookup record for. Pros and cons.
>
No cons that I can see.
It's a GREAT idea. I don't want/need email from users with ADSL or
cable modem servers that refuse to use their ISP's relay. If enough of
us stand firm on our mail acceptance policies to the point where we
force SOHO and "Linux Weenies" to use their ISP's relay (which
shouldn't cost them any money), then SPAMmers would take a huge hit.
SteveJ
That stuff is expensive!
> 2.7.1 was Wietse's latest stable when Debian froze the
> testing code base in prep for the release, which should occur within a month or
> so. Historically Debian has suffered from many stale packages, no argument
> there. But now that the backports project is an official part of Debian,
See, I did not know this.
Last I used Debian-pure (instead of Ubuntu), you had to mess with
unstable to get up-to-date packages.
> this
> situation has become much better. BTW, I'm running backport 2.7.1. How is that
> lagging behind WRT to a distro package? Wietse just released 2.8 as stable a
> few weeks ago. Do you expect distro maintainers to have packages ready the next
> day? ;)
I'm prepared to give them a week ;)
> CentOS 5.5, their latest, ships with Postfix 2.3.3, which hasn't been supported
> by Wietse for quite some time. A new install of CentOS 5.5 gives you an
> officially unsupported Postfix, thought I'm sure CentOS will support it.
>
> Now _that_ is "lagging behind something awful".
Awfulness is had, somehow.
--
J.
> Its a good idea, but this would limit a user from using a server on his
> residential ADSL from being an Email server,
As the directions in the file itself state, fix situations like this with a
simple whitelist. Given the number of hobbyist servers your MX will receive
mail from, the whitelist will be very small and easily manageable.
The ratio of hobbyist MTAs to spambots on a given residential subnet is going to
be something like 1:5,000 give or take. The math speaks in favor of blocking
the spambots and whitelisting the hobby MTAs.
--
Stan
> True. Some of the matches don't reject, but prepend this header:
> X-GenericStaticHELO
> What is this header used for?
This exists due to the grey area between "residential" and "business"
classification. Some providers offer static IP service to small businesses over
cable/xDSL but don't offer custom rDNS. We don't block on these rDNS patterns
outright because the probability is sufficiently high that the client MTA is
legit vs a spambot.
You, the OP, can use this header for scoring in a content filter such as SA.
Note that you can change this header string to whatever you choose. You can
also change the PREPEND to REJECT if you so choose. Modify the file/expressions
any way you see fit to meet your needs.
--
Stan
> FreeBSD had the 2.8 release in its ports system a few days after it was
> officially released. The 2.9(beta) release will be released into the
> ports system shortly. The original 2.8(beta) was available almost
> from its inception. The speed with which a package is made available to
> a system is directly proportionate to the amount of time and effort a
> maintainer wished to invest.
Well, I think there's a bit more to it than that. Some distros have various
policies in place that hinder rapid inclusion. That said, if Sahil were
associated with the Debian project instead of or in addition to FreeBSD, we'd
probably see current Postfix backports in Debian more quickly. :)
>> CentOS 5.5, their latest, ships with Postfix 2.3.3, which hasn't been
>> supported by Wietse for quite some time. A new install of CentOS 5.5
>> gives you an officially unsupported Postfix, thought I'm sure CentOS
>> will support it.
>>
>> Now _that_ is "lagging behind something awful".
>
> CentOS's support for current software is an abomination. I wonder why
> anyone takes it seriously.
I've pondered this myself, and the conclusion I come to is that they are
ignorant newbs who are enamored with the "free" version of Red Hat Enterprise
Linux. They look at the price tag of RHEL and think they're getting something
good for nothing. They just don't realize RHEL is not "good" and is years
behind current, and that CentOS is months to years behind RHEL.
I think I summed it up best when I stated CentOS uses an outdated distribution
as their upstream source.
--
Stan
Unfortunately the situation isn't quite that simple. Note the explanation I
gave for the header prepending. There are ISPs who only offer xDSL to business
clients, with static IPs, but without custom rDNS, and they don't want these
business clients relaying through their MSAs. Most are going to run their own
MX MTA anyway. We don't want to be throwing these babies out with the bath
water, nor the hobbyists. We're fighting spammers.
The battle that needs to be fought is getting all ISPs to implement TCP 25
outbound filtering across the board for residential lines, and only opening it
upon request. Some already do this in the states, but relatively few. That's
the better way to solve the spambot/zombie problem, not penalizing one or two
segments of ISP customers simply because they're on a "residential class"
broadband line. If a hobbyist knows how to run an MTA properly, and wants to
send/receive directly, we should not discourage that. And we shouldn't be
penalizing SOHOs doing the same.
Remember, we're fighting spam, not innocent bystanders who simply have the same
connectivity a bot infected PC sits behind.
--
Stan
Am 04.02.2011 11:20, schrieb J4K:
> I agree. I have plenty of colleagues who run their own mail servers from
> residential connections and they know how to set-up their machines.
Maybe, but if they are running a mailserver form dial-up ranges
mail seems not to be important for them because since many years
such ranges are blocked on many servers and spamfilter-services
We got a new iprange on a business line which was faulty marked as
dial-up and there was a lot of troubles until fixed from ISP
> Understandably, they are miffed by having to pay for a business line, or rack space in a
> data centre, when they are perfectly capable for doing this with a spare box at home
sorry, but this does not interest anybody
a v-server is cheaper than the energy for the box
> Back to the Stan's pcre file:- I've been running through the logs for
> rejects specifically caused by this file (or prepends). However I did
> not see any. Is there a string I could search for,
Try:
~$ egrep "Dynamic - Please|Generic - Please|X-GenericStatic" /your/mail/log
> and how could I white
> list IPs instead of editing the pcre file?
Whitelisting in Postfix is simply using an access table with an accept rather
than reject action. See man 5 access. Example:
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
check_recipient_access cidr:/etc/postfix/whitelist
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre
...
...
/etc/postfix/whitelist
10.1.2.3 OK
10.2.3.4 OK
192.168.0.0/16 OK
--
Stan
Ahh this better:
# egrep "Dynamic - Please|Generic - Please|X-GenericStatic"
/var/log/mail.log | wc -l
180
Thank-you for the example. Can the /etc/postfix/whitelist be an empty file?
# ls -l /etc/postfix/whitelist
-rw-r----- 1 root root 0 Feb 4 11:53 /etc/postfix/whitelist
Feb 4 11:53:17 logout postfix/smtpd[9365]: fatal: open
/etc/postfix/whitelist: No such file or directory
Nope, it cannot. I added a random
10.1.2.3 OK
and it worked.
Sure, and tons of VPS/cloud/etc IP space is summarily blocked by many smtp
receivers as well due to snowshoe spammer infestation, with Amazon being the
most well known, Slicehost, Rackspace, etc, etc. VPS at many receivers is just
as persona non grata as residential dynamic. So the solution is the same as
with SOHO and residential hobby servers: block all, whitelist a few as needed.
This class warfare of who can direct send legit mail from where does more to
damage the net that spammers ever could. Keep focused on the target: spammers.
This fight isn't about whose server sits in a gold plated data center on an
OC192 vs whose sits in Mom's basement on aDSL. Anyone concentrated on the
latter has already lost the fight.
--
Stan
/^ip[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.adsl2?\.static\.versatel\.nl$/
PREPEND X-GenericStaticHELO: (versatel.ml)
should read /ml/nl/
/^ip[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.adsl2?\.static\.versatel\.nl$/
PREPEND X-GenericStaticHELO: (versatel.nl)
> Well, I think there's a bit more to it than that. Some distros have
> various policies in place that hinder rapid inclusion. That said, if
> Sahil were associated with the Debian project instead of or in
> addition to FreeBSD, we'd probably see current Postfix backports in
> Debian more quickly. :)
Absolutely. He does a fabulous job with the ports he maintains for
FreeBSD. :) He will even answer questions directed at him. I have found
many maintainers that just cannot be bothered to assist anyone.
--
Jerry ✌
postfi...@seibercom.net
_____________________________________________________________________
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
Anyone stupid enough to be caught by the police is probably guilty.
And likewise on line 1589:
/^adsl-dc-[0-9]{4,6}\.adsl\.wanadoo\.nl$/ REJECT Generic -
Please relay via ISP (wanadoo.ml)
should probably be:
/^adsl-dc-[0-9]{4,6}\.adsl\.wanadoo\.nl$/ REJECT Generic -
Please relay via ISP (wanadoo.nl)
That pesky m sits pretty close to the n on the keyboard. :)
SteveJ
Some of us with older (but not THAT old) DELL hardware in our racks
are forced to run RHEL and/or CentOS, since it's the only distro DELL
official supports on that hardware. VERY recently, they've started
partnering with SuSE and Ubuntu as well, but for most of the stuff in
our racks, we're required to run RHEL to if we want system management
software, remote access, firmware updates, current drivers for RAID
adapters, etc.
Still, I am (well, WAS) disappointed that Postfix 2.3.3 is what
installs on CentOS 5.5 by default. But Postfix 2.8 wasn't that hard to
compile. :)
SteveJ
Did you try a one-byte file? "echo > /etc/postfix/whitelist" I am
sure that I've had empty lookup maps in the past.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
> On Fri, Feb 04, 2011 at 11:56:51AM +0100, J4K wrote:
> > > Thank-you for the example. Can the /etc/postfix/whitelist be an
> > > empty file?
> > Answering my own question:-
> >
> > # ls -l /etc/postfix/whitelist
> > -rw-r----- 1 root root 0 Feb 4 11:53 /etc/postfix/whitelist
> >
> > Feb 4 11:53:17 logout postfix/smtpd[9365]: fatal: open
> > /etc/postfix/whitelist: No such file or directory
The file's creation time is awfully close to the timestamp of the message.
Perhaps it did not exist at 11:53:17, but did at 11:53:18 or some time
later that same minute.
> Did you try a one-byte file? "echo > /etc/postfix/whitelist" I am
> sure that I've had empty lookup maps in the past.
No, the error message is quite clear, the file did not exist.
--
Viktor.
I always try to work with the package management system to keep things
sane and manageable if possible. postfix-2.7 and 2.8 rpms and srpms are
available for centos from several sources. It's pretty easy to replace
the ancient postfix package with a fairly up to date one, and it's one
of the first things I'd do after a centos or rhel install.
I see that rhel 6 comes with postfix-2.6.6 which is better, but still a
bit conservative. Not all of the rhel/centos packages are out of date,
but they do seem quite sluggish about making any MTA changes.
FWIW debian/ubuntu seem to be much more current on the versions of
postfix they ship, but even then it's not a bad idea to install a more
recent package than what they ship with.
Joe
On Fri, Feb 04, 2011 at 11:20:45AM +0100, J4K wrote:
> On 02/04/2011 05:17 AM, Stan Hoeppner wrote:
> > Steve Jenkins put forth on 2/3/2011 11:18 AM:
> >> On Thu, Feb 3, 2011 at 1:44 AM, J4K <ju...@klunky.co.uk> wrote:
> >>> Its a good idea, but this would limit a user from using a server on his
> >>> residential ADSL from being an Email server, and force them to use their
> >>> ISPs relay. Else they might have to upgrade to a business package or spend
> >>> more money for a static IP address that they can amend the reverse lookup
> >>> record for. Pros and cons.
Cons, yes, but that train has long ago left the station. It's a done
deal: today's Internet will not work for running mailservers from
dynamic IP space without a relayhost.
This is a dead horse. One might even go so far as to say:
'E's not pinin'! 'E's passed on! This 'orse is no more! He has ceased
to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft
of life, 'e rests in peace! If you hadn't nailed 'im to the stable
'e'd be pushing up the daisies! 'Is metabolic processes are now
'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off
'is mortal coil, run down the curtain and joined the bleedin' choir
invisibile!! THIS IS AN EX-'ORSE!!
To try to push this a bit toward topicality, please see this:
http://www.postfix.org/SOHO_README.html
which discusses options for Postfix users in a SOHO setting.
Steve:
> >> It's a GREAT idea. I don't want/need email from users with ADSL
> >> or cable modem servers that refuse to use their ISP's relay. If
> >> enough of us stand firm on our mail acceptance policies to the
> >> point where we force SOHO and "Linux Weenies" to use their ISP's
> >> relay (which shouldn't cost them any money), then SPAMmers would
> >> take a huge hit.
I run a small site, the largest part of which is a hobbyist-run and
mostly hoobyist-oriented free software project. Some of our target
audience are these "Weenies" as described, and indeed, I stand firm.
We don't accept mail from Zen-listed hosts. We don't whitelist,
although I would consider such a request if it involved a static IP
address. I will *not* whitelist PBL space. If you can't get yourself
off the PBL, you should not be sending mail direct-to-MX.
I used to feel exactly as J4K does. I learned why that won't work. My
hobbyist[1] project is hosted at a real datacenter, with static IP
and FCrDNS. When our provider messed up our rDNS recently, I switched
to using a relayhost at another site, which had good FCrDNS.
One thing I personally do which is not suitable now: I send mail as a
GMX user, but not through GMX relays. Since I only use this address
for mailing lists, I generally get away with it, but I doubt that
will last indefinitely. Eventually I'll have to DTRT: send using my
own domain, or submit GMX outbound through GMX relays.
Stan:
> > Unfortunately the situation isn't quite that simple. Note the
> > explanation I gave for the header prepending. There are ISPs who
> > only offer xDSL to business clients, with static IPs, but without
> > custom rDNS, and they don't want these business clients relaying
> > through their MSAs. Most are going to run their own MX MTA
> > anyway. We don't want to be throwing these babies out with the
> > bath water, nor the hobbyists. We're fighting spammers.
I agree with Stan in principle, but as much as possible, it's best
for those who have incompetent "business" ISPs to vote with their
feet. It's almost a corrolary of the Boulder Pledge. Demand value for
your money.
> > The battle that needs to be fought is getting all ISPs to
> > implement TCP 25 outbound filtering across the board for
> > residential lines, and only opening it upon request. Some
> > already do this in the states, but relatively few. That's the
> > better way to solve the spambot/zombie problem, not penalizing
> > one or two segments of ISP customers simply because they're on a
> > "residential class" broadband line. If a hobbyist knows how to
> > run an MTA properly, and wants to send/receive directly, we
> > should not discourage that. And we shouldn't be penalizing SOHOs
> > doing the same.
Again I agree in principle, but less so in practice. Outbound 25
blocking is good, but it's not worth trying to preach that to ISPs
who aren't doing it. If an ISP is a source of a lot of abuse, the
ideal thing to see is that ISP being widely blocked. And then its
customers will have to vote with their feet, if they want to use
Internet mail!
> > Remember, we're fighting spam, not innocent bystanders who simply
> > have the same connectivity a bot infected PC sits behind.
> >
> I agree. I have plenty of colleagues who run their own mail servers
> from residential connections and they know how to set-up their
> machines. Understandably, they are miffed by having to pay for a
> business line, or rack space in a data centre, when they are
> perfectly capable for doing this with a spare box at home.
> Therefore they set-up their own server.
Hogwash. If they do, they're using a relayhost. And if they really
are as capable as you say, they understand why this is necessary.
> I don't fancy blocking these people or the enthusiasts who are
> quite capable of running their own server.
Nevertheless, it's necessary.
> Back to the Stan's pcre file:- I've been running through the logs
> for rejects specifically caused by this file (or prepends).
> However I did not see any. Is there a string I could search for,
> and how could I white list IPs instead of editing the pcre file?
These questions (which are on topic, and I might reply under
separate cover if no one else has addressed them fully) betray your
lack of understanding of Postfix and email in general. Your sermon
about the "capable colleagues" is thus losing credibility.
Please, learn more about the state of SMTP in A.D. 2011, before
you go on about how those of us who understand it better are wrong.
Stan's right: we're fighting spammers, but perhaps he is a bit more
optimistic than I am about winning that fight. We try to limit the
damage they do ... best we can hope for as things stand now.
<plug shame-mode=no,shameless>
If you really do want to beat this dead horse, it would be well
within the topicality of a list I help run:
http://spammers.dontlike.us/
We have a lot of good folks there (and I know Stan will agree!) who
can and will teach you the folly of direct-to-MX mail from dynamic
and/or tainted IP space.
You'd be welcome to join us, and I guarantee it won't be any
rougher[2] on you than I was. :)
</plug>
[1] Do note, for me, the word, "hobbyist," is a term worthy of
highest respect in computing and free software. I'm always
appalled by the lack of quality among so-called IT
"professionals", and yet I know many bright and capable
computer hobbyists.
[2] I don't think I was "rough", per se, just direct. Since I said
nothing offensive, I shouldn't have to say this, but indeed no
offense was intended.
> I think there is a typo in the file:
>
> /^ip[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.adsl2?\.static\.versatel\.nl$/
> PREPEND X-GenericStaticHELO: (versatel.ml)
> should read /ml/nl/
> /^ip[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.adsl2?\.static\.versatel\.nl$/
> PREPEND X-GenericStaticHELO: (versatel.nl)
This thread is teetering on the edge of on/off topic. This particular aspect is
def off topic. Thanks for pointing out the error. Please next time email me a
correction like this off list.
Thanks.
--
Stan
guys, we at the bsd balcony find it funny to see linuxers fighting each
other with "my distro is better" and "I can compile faster than you",
and more funnily "I was born to destroy bill gates empire".
but all this is off topic here.
so bsd is the answer to all universe questions? *g
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
I'm at a loss as to where you think you're seeing a fight. I merely
mentioned options for upgrading postix packages on various linux
distros. I've used all the above mentioned distros and more. I have not
indicated a preference for one over the other, I consider them all useful.
Joe
maybe I took it the way I should not, but reading the messages again
doesn't help me change my mind. anyway, let's skip...
what I mean is: there's no point complaining about why a distro has old
packages. if you use a system/distro, you need to take into account both
the system and the packages. if you chose linux because "there's nothing
but linux", then chose a distro because "it's the best", then don't
complain about its packages. before you do, try to contribute.
> I merely
> mentioned options for upgrading postix packages on various linux
> distros. I've used all the above mentioned distros and more. I have not
> indicated a preference for one over the other, I consider them all useful.
>
so do I. I may have taken into account other discussions (from other
threads) where people complain about the package age in various distros.
I don't consider upgrading to the latest software, be that postfix or
apache, to be my religion. I certainly use the latest postfix version on
freebsd, even more recent than what the port provides (hey Sahil!), but
that's because I know how bsd pkgsrc/ports work and because it's easy.
for example, here's how to use the 2.9-20110120 on freebsd:
# cd /usr/ports/mail/
# cp -r postfix-current postfix-last
# cd postfix-last
-> change the DISTVERSION in Makefile
# vi Makefile
..
DISTVERSION= 2.9-20110120
..
-> download the tarball
# make fetch
-> compute sha1 & size and update distinfo:
# vi distinfo
SHA256 (postfix/postfix-2.9-20110120.tar.gz) =
88dae90c52aa7eabf2a6dd3a9c4364240062419ff6fd2a814f4910a0e991e7a7
SIZE (postfix/postfix-2.9-20110120.tar.gz) = 3638193
-> update pkg-plist to add tlsproxy (so that a pkg_delete removes all
the stuff)
# diff pkg-plist ../postfix-current/
37d36
< libexec/postfix/tlsproxy
234d232
< %%PORTDOCS%%%%DOCSDIR%%/tlsproxy.8.html
-> build and install
# make install clean
> Le 05/02/2011 00:34, Joe a écrit :
> > On 02/04/2011 03:13 PM, mouss wrote:
I have done the same thing with other packages on FreeBSD as well. From
what I can tell, the only reason that the latest 2.9x release is not in
the ports system is because of FreeBSD's retarded port freeze pending
the release of the updated OS. I would definitely NOT blame Sahil's
for this minor inconvenience or delay. He did get the 2.8 version out
almost as soon as it was officially released. I believe that I can
safely say that he beat every other distro out of the gate. He does a
magnificent job of maintaining the Postfix ports.