Re: Restricting port 25 with cidr table
On 20/1/2012 10:54 μμ, Wietse Venema wrote: > seems to me the same to use: > smtpd_client_restrictions = check_client_access > cidr:/etc/postfix/gwservers.cidr > where gwservers.cidr is: > xxx.xxx.xxx.xxx OK > xxx.xxx.xxx.xxx OK > 0.0.0.0/0 reject unauthorized client, please use our MX This "passes" IPv6 clients that match no rule. Thanks Wietsie. I understand. However, we could formulate gwservers.cidr as (for example): xxx.xxx.xxx.xxx OK xxx.xxx.xxx.xxx OK 127.0.0.1 OK :::::: OK :::::OK ::1 OK 0.0.0.0/0 reject unauthorized client, please use our MX ::/0 reject unauthorized client, please use our MX and then, using the above file with: smtpd_client_restrictions = check_client_access cidr:/etc/postfix/gwservers.cidr would be practically the same with using the following with a gwservers.cidr*without* the last two lines: smtpd_client_restrictions = check_client_access cidr:/etc/postfix/gwservers.cidr,reject of course only if there is nothing else before the ending ",reject" (in the latter). Additionally, it wouldn't hurt to add ",reject" to the former, but it would never be evaluated. So, I would tend to think it's more flexible to use the second type, because we could later add more rules before the ending ",reject". Am I right in the above? Thanks again, to both you and Charles who assisted me in clarifying things. Nick
Re: could not find any active network interfaces (no IPv6)
On 21/1/2012 2:49 πμ, Wietse Venema wrote: Try using strace. See http://www.postfix.org/DEBUG_README.html Trying to help from my past experience, I add here some details on this (I used Postfix 2.8.5 on CentOS 6 64bit): I added in /etc/postfix/main.cf: debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin; (strace -p $process_id 2>&1 | logger -p mail.info) & sleep 5 and then in /etc/postfix/master.cf: local unix - n n - - local -D You may want to see: http://tech.groups.yahoo.com/group/postfix-users/message/280554 Good luck, Nick
Re: forwarding to 2 domains
On Wed, 18 Jan 2012 16:35:50 +, João Pagaime wrote: I almost got away with a configuration like this at " /etc/postfix/virtual" @DOM.com@DOM1.com, @DOM2.com u...@dom.comu...@dom1.com,u...@dom2.com this is the syntax, stop using catchall
Re: Declaring options for submission port daemon
On Thu, 19 Jan 2012 17:10:00 -0500 (EST), Wietse Venema wrote: > I found these with: postconf | grep '[A-Z][A-Z][A-Z]:' :-) postconf | grep '[A-Z][A-Z][A-Z]:' :-) results in: bash: syntax error near unexpected token `)' ... and at my system man grep refuses to show what that last :-) switch stands for. M.
Re: Postfix very slow accepting a mail having a massive recipient list
On 20.01.2012 16:01, Stan Hoeppner wrote: > On 1/20/2012 1:50 AM, Michael Tokarev wrote: > >> Please excuse me for the somewhat harsh words, but except of the >> alignment issues which should be solved for once when partitioning >> and creating filesystem, the rest is a complete bullshit collected >> from various forums where people does not understand what they're >> doing and blame bad drives. > > Since I am apparently the target of "does not understand what they're > doing and blame bad drives" let me give you some education that isn't > "bullshit" from "various forums", but knowledge gained from working with > hard disk drive technology for over 25 years, designing RAID storage > systems for a few of those, and cutting my teeth when drives were still > called "Winchesters". I will explain in detail why these 'green' drives > aren't suitable for mail queue and other high random IOPS workloads. It looks like we're coming from the same place/background/time but apparently do not share the conclusions. I referred to forums because lots of people really don't understand what's going on and just blame the drives, -- this is something which do exists. >> These drives are excellent when set up and used properly (the >> misalignment issue you mentioned is real indeed, and MUST be >> taken into account: everything should be aligned to 4Kb, lots >> of especially old tools don't do that or even don't LET you to >> do that - eg cfdisk in linux). Very reliable, fast and >> predictable. > > As it turns out the OP has Seagate LP drives which are not Advanced > Format 512/4096 drives. No alignment issue there. I never had/usd these so don't know. Apparently the LP drives are more optimized for sequentional operations, since they're positioned for various media tasks (movies, photos etc) - but again it is difficult to say what is "optimization" here. But that's not the point, I commented on your general conclusion not the particular drive model. > And he's using EXT4, > not XFS, so there's not really a possibility of filesystem misalignment > on the RAID stripe, as EXT4 isn't advanced enough to align to the > underlying RAID stripe. This is, again, somewhat over-statement. But it is not the point here again. >> I'll give just one note about speed, which may look completely >> wrong at first. The reason they're speedy is that at their >> low rotational speed, they also have much more data density, -- >> ie, basically, they can transfer much more data during single >> rotate. This way, their linear speed (sequentional read or >> write) often goes FASTER than enterprize-class 15KRPM drives >> which are of much less volumes (300-600Gb as opposed to 1 or >> 2Tb or more for these "green" drives). > > This argument is flawed. Lower spindle speed doesn't create higher > aerial density--there is no relationship between the two. And higher > aerial density doesn't dictate a lower spindle speed. This is simply a > design tradeoff/decision. I never said higher density is BECAUSE lower rotational speed or vise versa. But there _is_ a very strong relationship between the two: you can't have _both_ because at higher speed you can NOT read/write high-density data due to very high requiriments for the mechanical parts in this case. > Higher aerial density will yield a higher > sequential data rate. But lower spindle speed will ALWAYS yield a lower > random transaction rate. The former is irrelevant to mail server > (queue) performance. The latter is key to mail server (queue) performance. Both true and I never tried to state the opposite, except of one detail questioning the "ALWAYS" part, here: >> Yes, due to slower rotational speed, they take more time to >> position platter to the right place. But that's, again, not >> whole story: the seek time is about the same as for their >> "elder" brothers. Now, use just first 300 or 600Gb out of >> this 2Tb drive, to have more fair comparison with 15KRPM >> drives, and you realize that the seek time improves greatly, >> since we now have to seek less! > > Flawed again. For 4 reasons: > > 1. The "seek time" isn't anywhere close to the same. The > track-to-track seek latency will be similar because the actuator motors > are very similar. But the full stroke seek latency will be over twice > as high for the 'green' drives. This is critically important because > green drives, especially the WD models, aggressively park their heads > every few seconds to save power. When the head is not parked there must > always be current in the voice coil to maintain head position. Parking > the heads aggressively saves power as the coil is not energized when the > head is parked. Thus, on the next access, the heads must move all the > way from the parking ramp to the target track. This un-parking latency > isn't included in the "average latency" figures advertised. That's lots of details in one statement. Parking isn't mandatory and can be turned off, and if t
Re: Postfix very slow accepting a mail having a massive recipient list
On 21.01.2012 15:42, Michael Tokarev wrote: > On 20.01.2012 16:01, Stan Hoeppner wrote: [] >> As it turns out the OP has Seagate LP drives which are not Advanced >> Format 512/4096 drives. No alignment issue there. > > I never had/usd these so don't know. Apparently the LP drives > are more optimized for sequentional operations, since they're > positioned for various media tasks (movies, photos etc) - but > again it is difficult to say what is "optimization" here. There are 2 modifications of Barracuda LP drives. For 1Gb models, these are LP ST31000520AS (with traditional 512-sized sectors) and LP ST1000DL002, with advanced format (4kb phys sectors). Both has 5.9KRPM rotation speed. FWIW. [] > My mistake about smtp-sink vs smtp-source, indeed you're right > here. What I mean to say here is that - just out of curiocity - > I measured postfix speed on my home machine when I bought one > of these WD greens - because I really was curious whenever all > the speed issues which were mentioned on lots of forums are true. > It was in the beginning of 2010, ie, about a year ago. It was in the beginning of 2011, not 2010. > And having said all that, I think it'd be interesting to > understand why the OP has this slow system. It should not > be this slow, with non-AF drives (misalignment for AF drives > can explain this slowness, and that's the only thing I can > think of right now). Yes there are several layers of storage, > but that should not be _that_ bad. Maybe that's the LP drives, > I dunno. So it very well might be due to misalignment. /mjt
Re: could not find any active network interfaces (no IPv6)
Wietse Venema: > Try using strace. See http://www.postfix.org/DEBUG_README.html Alternatively, try Postfix 2.9.0-RC1. This has some failure tolerance features built-in, and may produce more informative diagnostics. Wietse
Re: Problem with SMTPs SSL_accept error | lost connection after CONNECT
On 1/21/2012 12:05 AM, Benny Pedersen wrote: >>> Jan 18 18:20:54 newmail postfix/smtpd[83432]: lost connection >>> after CONNECT from >>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] > >>> What would you advise me to further debug this ? > > CONNECT is a non SMTP protocol, are you running tor or squid ?, > sugest ipfirewall block CONNECT ips No, this has nothing to do with the on-wire protocol. In this context, CONNECT means the initial tcp/ip handshake completed. "lost connection after connect" simply means the initial handshake completed, then the connection dropped before any commands were exchanged. -- Noel Jones
Re: Declaring options for submission port daemon
On 1/21/2012 5:08 AM, Mark Alan wrote: > On Thu, 19 Jan 2012 17:10:00 -0500 (EST), Wietse Venema > wrote: > >> I found these with: postconf | grep '[A-Z][A-Z][A-Z]:' :-) > > postconf | grep '[A-Z][A-Z][A-Z]:' :-) results in: > bash: syntax error near unexpected token `)' > > ... and at my system man grep refuses to show what that > last :-) switch stands for. > > M. That's a smiley face, not part of the command postconf | grep '[A-Z][A-Z][A-Z]:' -- Noel Jones
Re: Postfix very slow accepting a mail having a massive recipient list
On 1/21/2012 6:53 AM, Michael Tokarev wrote: > On 21.01.2012 15:42, Michael Tokarev wrote: >> On 20.01.2012 16:01, Stan Hoeppner wrote: > [] >>> As it turns out the OP has Seagate LP drives which are not Advanced >>> Format 512/4096 drives. No alignment issue there. >> >> I never had/usd these so don't know. Apparently the LP drives >> are more optimized for sequentional operations, since they're >> positioned for various media tasks (movies, photos etc) - but >> again it is difficult to say what is "optimization" here. > > There are 2 modifications of Barracuda LP drives. For 1Gb > models, these are LP ST31000520AS (with traditional 512-sized > sectors) Seagate is apparently playing a shell game with branding. They sell some of the 512 byte/sector 5.9K rpm "LP" drives as both "LP" and "Green" models. Regardless all "LP" drives are 512B/sector. and LP ST1000DL002, with advanced format (4kb phys > sectors). Both has 5.9KRPM rotation speed. FWIW. ST1000DL002 is a Barracuda Green, not a Barracuda LP, according to Seagate's branding. And according to Seagate, all of the 5900 rpm "Barracuda LP" drives from 500GB to 2TB have 512 byte sectors: http://www.seagate.com/docs/pdf/datasheet/disc/ds_barracuda_lp.pdf Due to Seagate's cross-branding I guess it's possible his drives are actually 4096byte/sector models. In which case mis-alignment is a possible factor in his horrible fsync performance. It's impossible to say as the OP didn't state the actual model number. On a _technical_ mailing list that's really a requirement. >> And having said all that, I think it'd be interesting to >> understand why the OP has this slow system. It should not >> be this slow, with non-AF drives (misalignment for AF drives >> can explain this slowness, and that's the only thing I can >> think of right now). Yes there are several layers of storage, >> but that should not be _that_ bad. Maybe that's the LP drives, >> I dunno. > > So it very well might be due to misalignment. It's probably a combination of things. But lacking further information from Konrad there's nothing further we can do but fruitlessly speculate. So until we have more information I think this thread should die. -- Stan
Postfix 2.8 + and Berkerley DB > 4.7
Any issues with Berkeley DB > 4.7 with current Postfix ? -- Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca God, Queen and country! Never Satan President Republic! Beware AntiChrist rising! https://www.fullyfollow.me/rootnl2k Birthdate : 29 Jan 1969 Croydon, Surrey, UK
