subject:"Bug"


OS:Gentoo latest built with kernel 3.2.1 with hardened profile
POSTFIX: v 2.9.1
when i'm configuring on master.cf some listening to port on ip address 
that doesn't exist on any interface such as for communicating with 
amavis (as if my ip is 192.168.0.20 and i will put 192.168.0.21:25 )
postfix will try to bind the port\ip and will not run or log useful 
information to understand whats wrong extactly.
then you can't find any process of postfix using ps top or any other 
tool but postfix will say that it is still running and the only way i 
managed to make postfix work is to fix the master.cf and rebooting the 
machine\os.


Thanks,
Eliezer

Re: found a bug on postfix 2.9.1

Eliezer Croitoru:
 OS:Gentoo latest built with kernel 3.2.1 with hardened profile
 POSTFIX: v 2.9.1
 when i'm configuring on master.cf some listening to port on ip address 
 that doesn't exist on any interface such as for communicating with 
 amavis (as if my ip is 192.168.0.20 and i will put 192.168.0.21:25 )
 postfix will try to bind the port\ip and will not run or log useful 
 information to understand whats wrong extactly.
 then you can't find any process of postfix using ps top or any other 
 tool but postfix will say that it is still running and the only way i 
 managed to make postfix work is to fix the master.cf and rebooting the 
 machine\os.

To report a problem, please follow instructions in the mailing
list welcome message. Instead of an eye witness report, provide
concrete evidence from the configuration and logfiles.

Like this:

/etc/postfix/master.cf:
1.2.3.4:25 inet  n   -   n   -   1   whatever

# postfix stop
# postfix start
# tail -3 /var/log/maillog
Mar  6 06:53:25 tail postfix/master[60082]: terminating on signal 15
Mar  6 06:53:28 tail postfix/postfix-script[4760]: starting the Postfix mail 
system
Mar  6 06:53:28 tail postfix/master[4761]: fatal: bind 1.2.3.4 port 25: Can't 
assign requested address

Wietse

Re: found a bug on postfix 2.9.1

Wietse Venema:
 Eliezer Croitoru:
  OS:Gentoo latest built with kernel 3.2.1 with hardened profile
  POSTFIX: v 2.9.1
  when i'm configuring on master.cf some listening to port on ip address 
  that doesn't exist on any interface such as for communicating with 
  amavis (as if my ip is 192.168.0.20 and i will put 192.168.0.21:25 )
  postfix will try to bind the port\ip and will not run or log useful 
  information to understand whats wrong extactly.
  then you can't find any process of postfix using ps top or any other 
  tool but postfix will say that it is still running and the only way i 
  managed to make postfix work is to fix the master.cf and rebooting the 
  machine\os.
 
 To report a problem, please follow instructions in the mailing
 list welcome message. Instead of an eye witness report, provide
 concrete evidence from the configuration and logfiles.
 
 Like this:
 
 /etc/postfix/master.cf:
 1.2.3.4:25 inet  n   -   n   -   1   whatever
 
 # postfix stop
 # postfix start
 # tail -3 /var/log/maillog
 Mar  6 06:53:25 tail postfix/master[60082]: terminating on signal 15
 Mar  6 06:53:28 tail postfix/postfix-script[4760]: starting the Postfix mail 
 system
 Mar  6 06:53:28 tail postfix/master[4761]: fatal: bind 1.2.3.4 port 25: Can't 
 assign requested address

Also:

# postfix status
postfix/postfix-script: the Postfix mail system is not running

If you can post your evidence, then we can look for differences.

Wietse

Re: found a bug on postfix 2.9.1

2012-03-06 Thread Jerry

On Tue, 06 Mar 2012 12:37:02 +0200
Eliezer Croitoru articulated:

 OS:Gentoo latest built with kernel 3.2.1 with hardened profile
 POSTFIX: v 2.9.1
 when i'm configuring on master.cf some listening to port on ip
 address that doesn't exist on any interface such as for communicating
 with amavis (as if my ip is 192.168.0.20 and i will put
 192.168.0.21:25 ) postfix will try to bind the port\ip and will not
 run or log useful information to understand whats wrong extactly.
 then you can't find any process of postfix using ps top or any other 
 tool but postfix will say that it is still running and the only way i 
 managed to make postfix work is to fix the master.cf and rebooting
 the machine\os.

You need to provide the proper information to debug a possible bug.
Start here: http://www.postfix.com/DEBUG_README.html

Be sure to read this part thoroughly:
http://www.postfix.com/DEBUG_README.html#mail

Report back with the requested information and then someone can
possibly assist you.

-- 
Jerry ✌
postfix-u...@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

Re: found a bug on postfix 2.9.1

On Tue, Mar 06, 2012 at 07:03:04AM -0500, Wietse Venema wrote:
  /etc/postfix/master.cf:
  1.2.3.4:25 inet  n   -   n   -   1   whatever
  
  # postfix stop
  # postfix start
  # tail -3 /var/log/maillog
  Mar  6 06:53:25 tail postfix/master[60082]: terminating on signal 15
  Mar  6 06:53:28 tail postfix/postfix-script[4760]: starting the Postfix 
  mail system
  Mar  6 06:53:28 tail postfix/master[4761]: fatal: bind 1.2.3.4 port 25: 
  Can't assign requested address
 
 Also:
 
 # postfix status
 postfix/postfix-script: the Postfix mail system is not running

# grep 1.2.3.4 /etc/postfix/master.cf 
1.2.3.4:25  inet  n   -   n   -   -   smtpd
# postfix start
postfix/postfix-script: starting the Postfix mail system
# echo $?
0
# tail -n2 /var/log/everything/current 
Mar 06 14:31:45 [postfix/postfix-script] starting the Postfix mail
system
Mar 06 14:31:45 [postfix/master] fatal: bind 1.2.3.4 port 25: Cannot
assign requested address

The return code of zero from postfix start trips the init script.  OP
should run /etc/init.d/postfix zap to return postfix to stopped state,
correct master.cf and start postfix again.  This is arguably no different
from any number of configuration errors resulting in a non working setup.

In any case, bugs.gentoo.org or a gentoo mailing list is probably the
correct place for this discussion.
-- 
Eray Aslan

Re: found a bug on postfix 2.9.1

Eray Aslan:
 # postfix start
 postfix/postfix-script: starting the Postfix mail system
 # echo $?
 0

As documented in the Postfix manpage:

   start  Start  the Postfix mail system. This also runs the configuration
  check described above.

   status Indicate if the Postfix mail system is currently running.

Init/upstart/systemd/launchpad/whatever scripts are OS-specific.
They are not part of Postfix. They are the responsibility of the
OS-specific port maintainer.

I would also like to reiterate that the postfix command is the
sole supported interface for starting and stopping Postfix. All
support of Postfix is canceled when start/stop/status are managed
by direct manipulation of the Postfix master daemon.

Wietse

Re: found a bug on postfix 2.9.1

On Tue, Mar 06, 2012 at 08:40:16AM -0500, Wietse Venema wrote:
start  Start  the Postfix mail system. This also runs the configuration
 check described above.
 
status Indicate if the Postfix mail system is currently running.

This does introduce a non-negligible delay in startup for everyone but
yes, it is better.  Thanks.

 I would also like to reiterate that the postfix command is the
 sole supported interface for starting and stopping Postfix.

Aye, noted.

-- 
Eray Aslan

Re: found a bug on postfix 2.9.1

Eray Aslan:
 On Tue, Mar 06, 2012 at 08:40:16AM -0500, Wietse Venema wrote:
 start  Start  the Postfix mail system. This also runs the configuration
check described above.
  
 status Indicate if the Postfix mail system is currently running.
 
 This does introduce a non-negligible delay in startup for everyone but
 yes, it is better.  Thanks.

I think that making everyone wait would be another example of
well-meaning people doing things that give Postfix a bad reputation.

Examples of common maintainer-induced damage:

- Turning on IPv6 by default. SUSE does this, making remote
destinations unreachable that have five or more IPv6 addresses.
Postfix 2.9 has a defense for such brain damage.

- Turning on chroot by default. Many Debian etc. users get into
trouble when they make an innocuous configuration change to the
SMTP daemon. Postfix has no defense for this brain damage.

Wietse

Re: [SPAM] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Stéphane MERLE




Le 06/03/2012 17:48, Wietse Venema a écrit :

Eray Aslan:

On Tue, Mar 06, 2012 at 08:40:16AM -0500, Wietse Venema wrote:

start  Start  the Postfix mail system. This also runs the configuration
  check described above.

status Indicate if the Postfix mail system is currently running.

This does introduce a non-negligible delay in startup for everyone but
yes, it is better.  Thanks.

I think that making everyone wait would be another example of
well-meaning people doing things that give Postfix a bad reputation.

Examples of common maintainer-induced damage:


I thought that every packet maintainer would contact you before hand to 
have a procedure ?


I am so naif sometimes 

Stéphane



- Turning on IPv6 by default. SUSE does this, making remote
destinations unreachable that have five or more IPv6 addresses.
Postfix 2.9 has a defense for such brain damage.

- Turning on chroot by default. Many Debian etc. users get into
trouble when they make an innocuous configuration change to the
SMTP daemon. Postfix has no defense for this brain damage.

Wietse

Re: found a bug on postfix 2.9.1

2012-03-06 Thread Stan Hoeppner

On 3/6/2012 10:48 AM, Wietse Venema wrote:

 - Turning on chroot by default. Many Debian etc. users get into
 trouble when they make an innocuous configuration change to the
 SMTP daemon. Postfix has no defense for this brain damage.

Is this the syslog socket issue Wietse or another issue?  Debian added a
syslog socket quite a while back.  IIRC it was not long after you helped
me troubleshoot my logging problem caused by lack of the socket.

-- 
Stan

Re: found a bug on postfix 2.9.1

Eray Aslan:
 On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote:
  I think that making everyone wait would be another example of
  well-meaning people doing things that give Postfix a bad reputation.
 
 postfix start exits successfully but postfix doesn't work, resulting in a
 WTF moment for the user.  I am not sure if this is a recommended way to
 start a daemon.  It surprises them - hence the original email.

According to the original complaint, no error was logged, and the
system claimed that the mail system was running.

If they had looked in the right logfile, and if they had used the
postfix status command, all this WTF would have been unnecessary.

They also claimed they had to to reboot their system to clear up
the problem.

All this indicates that they have no clue. Going for the lowest
common denominator is not sufficient moditivation to make changes
that cause everyone else to suffer.

Wietse

[OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Michael Orlitzky

On 03/06/12 14:10, Wietse Venema wrote:
 Eray Aslan:
 On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote:
 I think that making everyone wait would be another example of
 well-meaning people doing things that give Postfix a bad reputation.

 postfix start exits successfully but postfix doesn't work, resulting in a
 WTF moment for the user.  I am not sure if this is a recommended way to
 start a daemon.  It surprises them - hence the original email.
 
 According to the original complaint, no error was logged, and the
 system claimed that the mail system was running.
 
 If they had looked in the right logfile, and if they had used the
 postfix status command, all this WTF would have been unnecessary.
 
 They also claimed they had to to reboot their system to clear up
 the problem.
 
 All this indicates that they have no clue. Going for the lowest
 common denominator is not sufficient moditivation to make changes
 that cause everyone else to suffer.

It's not really his fault. This is what the startup message looks like:

  backup2 ~ # /etc/init.d/postfix start
   * Starting postfix (/etc/postfix)...  [ ok ]

If postfix has failed to actually start, you get the same message. Moreover,

  backup2 ~ # killall -9 /usr/lib64/postfix/master
  backup2 ~ # /etc/init.d/postfix start
   * WARNING: postfix has already been started
  backup2 ~ # /etc/init.d/postfix status
   * status: started

This is not ideal, but I wouldn't say it should necessarily be fixed,
either. Right now the problem is easy to understand: half of the time on
Gentoo, the startup OK is meaningless. Everyone knows this, and
figures out how to deal with it quickly:

  backup2 ~ # /etc/init.d/postfix stop
   * Stopping postfix (/etc/postfix)...  [ !! ]
   * ERROR: postfix failed to stop
  backup2 ~ # /etc/init.d/postfix zap
   * Manually resetting postfix to stopped state
  backup2 ~ # /etc/init.d/postfix start
   * Starting postfix (/etc/postfix)...  [ ok ]

If we try to fix it with magic (e.g. wrapping 'postfix status'),

  a) We require more developer time
  b) Some easy failure modes get nicer
  c) Many tricky failures get worse

So the benefit is not clear-cut.

Re: [OT] Re: found a bug on postfix 2.9.1

Michael Orlitzky:
   backup2 ~ # killall -9 /usr/lib64/postfix/master
   backup2 ~ # /etc/init.d/postfix start
* WARNING: postfix has already been started

That is a bug in an init script, and is the responsibility
of the OS-specific maintainer. Postfix does not provide
init/upstart/systemd/launchpad/whatever scripts.

Wietse

Re: [OT] Re: found a bug on postfix 2.9.1

On Tue, Mar 06, 2012 at 02:30:59PM -0500, Michael Orlitzky wrote:
 either. Right now the problem is easy to understand: half of the time on
 Gentoo, the startup OK is meaningless. Everyone knows this, and
 figures out how to deal with it quickly:
 
   backup2 ~ # /etc/init.d/postfix stop
* Stopping postfix (/etc/postfix)...  [ !! ]
* ERROR: postfix failed to stop

You get this error because your system thinks postfix is running because
the init script exited successfully because postfix start exited
successfully (but postfix bailed out with wrong configuration).  With
postfix status check added, the init script, hence your system, would
work as expected and you won't be getting the above or similar errors,
i.e. there would be no need for the zap  start workaround.

Downside:
It would take ~1sec more to start up postfix *for everyone* - one has to
wait a bit before running postfix status after postfix start.

So, yes it is not a clear cut decision but for different reasons.

This is getting really off topic.

-- 
Eray Aslan

Re: [OT] Re: found a bug on postfix 2.9.1

Eray Aslan:
 On Tue, Mar 06, 2012 at 02:30:59PM -0500, Michael Orlitzky wrote:
  either. Right now the problem is easy to understand: half of the time on
  Gentoo, the startup OK is meaningless. Everyone knows this, and
  figures out how to deal with it quickly:
  
backup2 ~ # /etc/init.d/postfix stop
 * Stopping postfix (/etc/postfix)...  [ !! ]
 * ERROR: postfix failed to stop
 
 You get this error because your system thinks postfix is running because
 the init script exited successfully because postfix start exited
 successfully (but postfix bailed out with wrong configuration).  With
 postfix status check added, the init script, hence your system, would
 work as expected and you won't be getting the above or similar errors,
 i.e. there would be no need for the zap  start workaround.
 
 Downside:
 It would take ~1sec more to start up postfix *for everyone* - one has to
 wait a bit before running postfix status after postfix start.

So you need a way for postfix start that returns status 0 if the
master(8) daemon initalizes successfully, and non-zero otherwise.

I think this can be done by starting the master as a foreground
process.  The foreground master forks a child process that will
become the master daemon that runs as a background process. 

The foreground master process waits for the all is OK signal from
the child process. When that happens, the foreground process
terminates with a 0 status, causing postfix start to return a 0
status.  This will normally take a fraction of a second.

In case of problems (no response from child, child terminates) the
foreground process terminates with non-zero status, and postfix
start reports an error, and returns a non-zero exit status.

Will that work?

Wietse

Re: [OT] Re: found a bug on postfix 2.9.1

On Tue, Mar 06, 2012 at 04:01:47PM -0500, Wietse Venema wrote:
 So you need a way for postfix start that returns status 0 if the
 master(8) daemon initalizes successfully, and non-zero otherwise.

Correct.

 I think this can be done by starting the master as a foreground
 process.  The foreground master forks a child process that will
 become the master daemon that runs as a background process. 
 
 The foreground master process waits for the all is OK signal from
 the child process. When that happens, the foreground process
 terminates with a 0 status, causing postfix start to return a 0
 status.  This will normally take a fraction of a second.
 
 In case of problems (no response from child, child terminates) the
 foreground process terminates with non-zero status, and postfix
 start reports an error, and returns a non-zero exit status.
 
 Will that work?

Yes, that will work.  Thank you.

-- 
Eray Aslan

Re: found a bug on postfix 2.9.1


On 06/03/2012 21:10, Wietse Venema wrote:

Eray Aslan:

On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote:

I think that making everyone wait would be another example of
well-meaning people doing things that give Postfix a bad reputation.


postfix start exits successfully but postfix doesn't work, resulting in a
WTF moment for the user.  I am not sure if this is a recommended way to
start a daemon.  It surprises them - hence the original email.


According to the original complaint, no error was logged, and the
system claimed that the mail system was running.
sorry for the delay i was working the whole day on the mail system (that 
works perfect for the last 4 plus years based on postfix..it's that good)
i indeed found this log entry but it was difficult cause of the huge 
amount of mail.log by other mail service.


so i have used postfix start (not script)to start postfix and i got the 
error on log but it shows only once and then every time it saying 
something that i cant remember right now (side of effect of working on 
crisis mode for the last couple of weeks).


anyway postfix check command didnt showed any information about this 
problem.


Thanks
Eliezer




If they had looked in the right logfile, and if they had used the
postfix status command, all this WTF would have been unnecessary.

They also claimed they had to to reboot their system to clear up
the problem.

All this indicates that they have no clue. Going for the lowest
common denominator is not sufficient moditivation to make changes
that cause everyone else to suffer.

Wietse

Re: [OT] Re: found a bug on postfix 2.9.1


On 06/03/2012 21:30, Michael Orlitzky wrote:

On 03/06/12 14:10, Wietse Venema wrote:

Eray Aslan:

On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote:

I think that making everyone wait would be another example of
well-meaning people doing things that give Postfix a bad reputation.


postfix start exits successfully but postfix doesn't work, resulting in a
WTF moment for the user.  I am not sure if this is a recommended way to
start a daemon.  It surprises them - hence the original email.


According to the original complaint, no error was logged, and the
system claimed that the mail system was running.

If they had looked in the right logfile, and if they had used the
postfix status command, all this WTF would have been unnecessary.

They also claimed they had to to reboot their system to clear up
the problem.

All this indicates that they have no clue. Going for the lowest
common denominator is not sufficient moditivation to make changes
that cause everyone else to suffer.


It's not really his fault. This is what the startup message looks like:

   backup2 ~ # /etc/init.d/postfix start
* Starting postfix (/etc/postfix)...  [ ok ]

If postfix has failed to actually start, you get the same message. Moreover,

   backup2 ~ # killall -9 /usr/lib64/postfix/master
   backup2 ~ # /etc/init.d/postfix start
* WARNING: postfix has already been started
   backup2 ~ # /etc/init.d/postfix status
* status: started

This is not ideal, but I wouldn't say it should necessarily be fixed,
either. Right now the problem is easy to understand: half of the time on
Gentoo, the startup OK is meaningless. Everyone knows this, and
figures out how to deal with it quickly:

   backup2 ~ # /etc/init.d/postfix stop
* Stopping postfix (/etc/postfix)...  [ !! ]
* ERROR: postfix failed to stop
   backup2 ~ # /etc/init.d/postfix zap
* Manually resetting postfix to stopped state
   backup2 ~ # /etc/init.d/postfix start
* Starting postfix (/etc/postfix)...  [ ok ]

If we try to fix it with magic (e.g. wrapping 'postfix status'),

   a) We require more developer time
   b) Some easy failure modes get nicer
   c) Many tricky failures get worse
i dont care about any init scripts on whatever else then when there is 
this specific problem of mismatching binding an ip that dosnt exist to 
be checked using the postfix check method on terminal and not only on log.


by writing the bug i do hope this simple guy that will look for the 
problem will understand what could he missed.


Thanks,
Eliezer


So the benefit is not clear-cut.

Re: [OT] Re: found a bug on postfix 2.9.1

Eliezer Croitoru:
 i dont care about any init scripts on whatever else then when there is 
 this specific problem of mismatching binding an ip that dosnt exist to 
 be checked using the postfix check method on terminal and not only on log.

Sorry, only the master daemon knows that it can't access the IP address.

To find out if Postfix runs, use postfix status. Don't use the
crap scripts from Linux maintainers. To find out why Postfix
does not run , read the logfile.

Wietse

Re: found a bug on postfix 2.9.1


On 06/03/2012 14:17, Jerry wrote:

On Tue, 06 Mar 2012 12:37:02 +0200
Eliezer Croitoru articulated:


OS:Gentoo latest built with kernel 3.2.1 with hardened profile
POSTFIX: v 2.9.1
when i'm configuring on master.cf some listening to port on ip
address that doesn't exist on any interface such as for communicating
with amavis (as if my ip is 192.168.0.20 and i will put
192.168.0.21:25 ) postfix will try to bind the port\ip and will not
run or log useful information to understand whats wrong extactly.
then you can't find any process of postfix using ps top or any other
tool but postfix will say that it is still running and the only way i
managed to make postfix work is to fix the master.cf and rebooting
the machine\os.


You need to provide the proper information to debug a possible bug.
Start here: http://www.postfix.com/DEBUG_README.html

will do.
i will try to be more accurate next time.
because of two servers migration i had sometime of understanding this 
better and will try to debug it with more accuracy.


Eliezer


Be sure to read this part thoroughly:
http://www.postfix.com/DEBUG_README.html#mail

Report back with the requested information and then someone can
possibly assist you.

Re: [OT] Re: found a bug on postfix 2.9.1


On 07/03/2012 02:33, Wietse Venema wrote:

Eliezer Croitoru:

i dont care about any init scripts on whatever else then when there is
this specific problem of mismatching binding an ip that dosnt exist to
be checked using the postfix check method on terminal and not only on log.


Sorry, only the master daemon knows that it can't access the IP address.

ok but it wont stop using postfix stop

Eliezer


To find out if Postfix runs, use postfix status. Don't use the
crap scripts from Linux maintainers. To find out why Postfix
does not run , read the logfile.

Wietse

Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Viktor Dukhovni

On Tue, Mar 06, 2012 at 04:01:47PM -0500, Wietse Venema wrote:

 So you need a way for postfix start that returns status 0 if the
 master(8) daemon initalizes successfully, and non-zero otherwise.
 
 I think this can be done by starting the master as a foreground
 process.  The foreground master forks a child process that will
 become the master daemon that runs as a background process. 
 
 The foreground master process waits for the all is OK signal from
 the child process. When that happens, the foreground process
 terminates with a 0 status, causing postfix start to return a 0
 status.  This will normally take a fraction of a second.
 
 In case of problems (no response from child, child terminates) the
 foreground process terminates with non-zero status, and postfix
 start reports an error, and returns a non-zero exit status.
 
 Will that work?

It'll could be an inconvenience for the folks at Apple, who start
master(8) directly via launchd.  However, since they've made no
attempt to have their patches adopted, ...  it is hard to take
their interests into account. Probably provided master -d continues
to run in the foreground, their stuff will not break in new ways. :-)

-- 
Viktor.

Re: milter adding header possible bug

2012-02-02 Thread Wietse Venema

Vladimir Vassiliev:
 
 Hi,
 
 it's a question more like to developers.
 I'm using commercial anti-spam Milter. It adds some headers to message, 
 particularly, 
 X-SpamTest-Status and X-SpamTest-Status-Extended. Problem is that only latter 
 of these two appears 
 in message. More of it, two copies of these header are added to message.
 Problem appears only for this two headers.
 Can this be a bug in Postfix (for example, something with substring search)?

I don't have the input before it is modified, so I need a copy of
the output after it is modified.

Wietse

 Here is excerpt from log generated by cleanup -v:
 
 Feb  2 11:46:18 mail postfix/cleanup[32561]: reply: SMFIR_ADDHEADER data 31 
 bytes
 Feb  2 11:46:18 mail postfix/cleanup[32561]: reply: SMFIR_CHGHEADER data 35 
 bytes
 Feb  2 11:46:18 mail postfix/cleanup[32561]: cleanup_upd_header: 1 
 X-SpamTest-Status Not detected
 Feb  2 11:46:18 mail postfix/cleanup[32561]: cleanup_find_header_start: index 
 1 name X-SpamTest Status
 Feb  2 11:46:18 mail postfix/cleanup[32561]: cleanup_find_header_start: index 
 0 name 
 X-SpamTest-Status type 78 offset 156313
 Feb  2 11:46:18 mail postfix/cleanup[32561]: cleanup_patch_header: 
 X-SpamTest-Status Not 
 detected at 156313
 Feb  2 11:46:18 mail postfix/cleanup[32561]: reply: SMFIR_ADDHEADER data 40 
 bytes
 Feb  2 11:46:18 mail postfix/cleanup[32561]: reply: SMFIR_CHGHEADER data 44 
 bytes
 Feb  2 11:46:18 mail postfix/cleanup[32561]: cleanup_upd_header: 1 
 X-SpamTest-Status-Extended 
 not_detected
 Feb  2 11:46:18 mail postfix/cleanup[32561]: cleanup_find_header_start: index 
 1 name 
 X-SpamTest-Status-Extended
 Feb  2 11:46:18 mail postfix/cleanup[32561]: cleanup_find_header_start: index 
 0 name 
 X-SpamTest-Status-Extended type 78 offset 156363
 Feb  2 11:46:18 mail postfix/cleanup[32561]: cleanup_patch_header: 
 X-SpamTest-Status-Extended 
 not_detected at 156363
 
 Postfix 2.6.12
 
 -- 
 Vladimir Vassiliev

PATCH: milter adding header possible bug

2012-02-02 Thread Wietse Venema

Vladimir Vassiliev:
 Hi,
 
 it's a question more like to developers.
 I'm using commercial anti-spam Milter. It adds some headers to message, 
 particularly, 
 X-SpamTest-Status and X-SpamTest-Status-Extended. Problem is that only latter 
 of these two appears 
 in message. More of it, two copies of these header are added to message.
 Problem appears only for this two headers.
 Can this be a bug in Postfix (for example, something with substring search)?

This was caused by a length check against the wrong string (the
header name that was found, instead of the header name that was
wanted).

I notice that this application does a lot of

ADDHEADER   header1 value1
CHGHEADER 1 header1 value1
ADDHEADER   header2 value2
CHGHEADER 2 header2 value2
ADDHEADER   header3 value3
CHGHEADER 3 header3 value3

And so on, i.e. the application adds a header and replaces it with
the same value.  I have added this as a test case to the source
code so it won't happen again.

As a workaround, the application could send just the ADDHEADER
requests, without the CHGHEADER requests that replace a header
by the same text.

Wietse

diff --exclude=man --exclude=html --exclude=README_FILES --exclude=.indent.pro 
--exclude=Makefile.in -cr 
/var/tmp/postfix-2.10-20120130/src/cleanup/cleanup_milter.c ./cleanup_milter.c
*** /var/tmp/postfix-2.10-20120130/src/cleanup/cleanup_milter.c Sat Jan 14 
20:39:14 2012
--- ./cleanup_milter.c  Thu Feb  2 09:35:03 2012
***
*** 845,852 
 /* Reset the saved PTR record and update last_type. */ ;
else if ((header_label == 0
  || (strncasecmp(header_label, STR(buf), len) == 0
!  (IS_SPACE_TAB(STR(buf)[len])
! || STR(buf)[len] == ':')))
  --index == 0) {
/* If we have a saved PTR record, it points to start of header. */
break;
--- 845,851 
 /* Reset the saved PTR record and update last_type. */ ;
else if ((header_label == 0
  || (strncasecmp(header_label, STR(buf), len) == 0
!  (strlen(header_label) == len)))
  --index == 0) {
/* If we have a saved PTR record, it points to start of header. */
break;

Documentation Bug

2011-10-13 Thread sven . kieske


Hello,

I found a small bug in the online documentation on this page:

http://www.postfix.org/postconf.5.html

The option message_size_limit is described as:

The maximal size in bytes of a message[..],

This is wrong and should be:

The maximal size in bits of a message[..].

Regards

Sven Kieske



smime.p7s
Description: S/MIME Kryptografische Unterschrift

Re: Documentation Bug

2011-10-13 Thread Wietse Venema

sven.kie...@compact.de:
 Hello,
 
 I found a small bug in the online documentation on this page:
 
 http://www.postfix.org/postconf.5.html
 
 The option message_size_limit is described as:
 
 The maximal size in bytes of a message[..],

The documentation is correct. 

As the documentation says maximal size in bytes of a message,
including envelope information. The limit also includes headers
that Postfix adds to the message such as Date:, From: and Received:.

Wietse

Re: Documentation Bug

2011-10-13 Thread sven . kieske


Am 13.10.2011 14:35, schrieb wie...@porcupine.org:

sven.kie...@compact.de:

Hello,

I found a small bug in the online documentation on this page:

http://www.postfix.org/postconf.5.html

The option message_size_limit is described as:

The maximal size in bytes of a message[..],


The documentation is correct.

As the documentation says maximal size in bytes of a message,
including envelope information. The limit also includes headers
that Postfix adds to the message such as Date:, From: and Received:.


Well, I have here an setup with message_size_limit being 2100, 
which, by your math would calculate to: 2100 bytes = 20507.8125 KiB 
= 20.027160645 MiB.


According to my math, where 8 bit equals 1 byte:

2100 bit = 2625000 byte = 2563.4765625 KiB = 2.503395081 MiB

We clearly have set up a maximum message size limit of the latter (2.5 
MiB). I don't get mail out of this system bigger than that.


Maybe I don't get it, or you use different representations of what is an 
byte or KB instead of KiB? If I'm seeing something wrong please point me 
to my failure. :-)


I noticed the part about the header, but we're talking about a 
difference of ~17 MiB. This large amount can't just be headers, can it?


Kind Regards

Sven




smime.p7s
Description: S/MIME Kryptografische Unterschrift

Re: Documentation Bug

2011-10-13 Thread Wietse Venema

sven.kie...@compact.de:
 We clearly have set up a maximum message size limit of the latter (2.5 
 MiB). I don't get mail out of this system bigger than that.

Prove it. Show some concrete evidence. Without that, no-one
can tell you what mistake you are making.

As per the mailing list welcome message:

Thank you for your interest in Postfix. Although I wrote a large
part of the software, my personal email is not the point of contact
for support or questions.

- Information about Postfix is at http://www.postfix.org/

- Send questions about Postfix to postfix-users@postfix.org
To subscribe, see: http://www.postfix.org/lists.html

Wietse

Re: Documentation Bug

2011-10-13 Thread Reindl Harald



Am 13.10.2011 17:00, schrieb sven.kie...@compact.de:
 Maybe I don't get it, or you use different representations of what is an byte 
 or KB instead 
 of KiB? If I'm seeing something wrong please point me to my failure. :-)

you are missing the fact that e-mail is a text-only protocol and so every 
binary part
is base64-encoded and so at 2 MB attachment can often be =3 MB as base64, 
there is
no way to fine-configure this because depending on the attachment the overhead 
can
be very different



signature.asc
Description: OpenPGP digital signature

Re: Documentation Bug

2011-10-13 Thread Stefan Palme

On Thu, 2011-10-13 at 17:11 +0200, Reindl Harald wrote:

 ... depending on the attachment the overhead can be very different


Base64 always encodes 3 original bytes into 4 base64-bytes, so the
factor to calculate the effective size for an attachment in an email is
always 4/3*original_size.

Of course, if an attachment is not base64-encoded, the effective size of
an attachment may differ...

-stefan-

Re: Documentation Bug

2011-10-13 Thread Wietse Venema

Stefan Palme:
 On Thu, 2011-10-13 at 17:11 +0200, Reindl Harald wrote:
 
  ... depending on the attachment the overhead can be very different
 
 Base64 always encodes 3 original bytes into 4 base64-bytes, so the
 factor to calculate the effective size for an attachment in an email is
 always 4/3*original_size.
 
 Of course, if an attachment is not base64-encoded, the effective size of
 an attachment may differ...

The quoted-printable encoding replaces one character by three.  Even
such a large amount of expansion would not explain why they can't
send a 2.5MB file, when the Postfix message-size limit is 20MB.

Wietse

Re: Documentation Bug

2011-10-13 Thread Charles Marcus

On 2011-10-13 11:00 AM, sven.kie...@compact.de sven.kie...@compact.de 
wrote:

Maybe I don't get it, or you use different representations of what is an
byte or KB instead of KiB? If I'm seeing something wrong please point me
to my failure. :-)


Or maybe you failed to read the welcome message when you joined the list?

Per the welcome message you received when you joined the list:

TO REPORT A PROBLEM see:
http://www.postfix.org/DEBUG_README.html#mail

This usually means postfix version, output of postconf -n and unedited 
NON-verbose (unless verbose are specifically requested by someone 
helping you) logs exhibiting the problem. Other details, like contents 
of master.cf, and maybe even platform/OS details may be necessary for 
certain issues.


In other words, PROVE that you have configured postfix as you say you 
have, and PROVE that such a configured postfix rejects a message that it 
should be allowing.


--

Best regards,

Charles

Postfix Bug, virtual transport

2011-07-29 Thread kianoush

Hello,

if you put this in file:   virtual (used for virtual transport)

___
t...@example.com   t...@example.com, i...@example.com
___

And you have Both Virtual Mailboxes:
t...@example.com
i...@example.com
in your virtual mailbox map


And when you send locally from anyem...@example.com on the same server using
SMTP, SASL Authentication or local sendmail (pickup) to t...@example.com

i...@example.com will receive two copies of the message


I know it is possible to achieve this behavior using sender and receiver bcc
 but  virtual doesn't seem to work fine in such case,

if you put something like:

___
t...@example.com   t...@example.com, i...@example.com@
sometransport.example.com
___


and sometransport.example.com  is a transport pipe  it will work properly


Best

Kianoush

Re: Postfix Bug, virtual transport

2011-07-29 Thread Wietse Venema

kianoush:
[ Charset ISO-8859-1 unsupported, converting... ]
 Hello,
 
 if you put this in file:   virtual (used for virtual transport)
 
 ___
 t...@example.com   t...@example.com, i...@example.com
 ___
 
 And you have Both Virtual Mailboxes:
 t...@example.com
 i...@example.com
 in your virtual mailbox map
 
 
 And when you send locally from anyem...@example.com on the same server using
 SMTP, SASL Authentication or local sendmail (pickup) to t...@example.com
 
 i...@example.com will receive two copies of the message

See http://www.postfix.org/FILTER_README.html, look for
the text with receive_override_options.

Wietse
 
 I know it is possible to achieve this behavior using sender and receiver bcc
  but  virtual doesn't seem to work fine in such case,
 
 if you put something like:
 
 ___
 t...@example.com   t...@example.com, i...@example.com@
 sometransport.example.com
 ___
 
 
 and sometransport.example.com  is a transport pipe  it will work properly
 
 
 Best
 
 Kianoush

reject_unauth_pipelining not working as I'd expect (bug?)

2011-07-07 Thread ricardus1867

Hi!

While crawling trough my logs, I've noticed a couple of bots getting
rejected because of Improper use of SMTP command pipelining because of the
reject_unauth_pipelining in smptd_recipient_restrictions. So I decided to
give the old sleep trick a try. Only for unknown hosts, ofc...

The http://www.postfix.org/postconf.5.html#sleep manual recommends

smtpd_client_restrictions =
sleep 1, reject_unauth_pipelining
smtpd_delay_reject = no

which I tried, but it didn't have the desired effect. While speaking to
early results in an improper command pipelining after HELO from ... entry
in the logs, the message does not get rejected. In fact, I can give all the
commands including the final dot before the greeting and it still gets
delivered.

So I tried

smtpd_client_restrictions =
sleep 1
smtpd_helo_restrictions =
reject_unauth_pipelining
smtpd_delay_reject = no

which works better, but still not as I'd expect it to. If I issue the
commands (HELO, MAIL, RCPT) before the greeting, the message gets rejected.
However, if I issue only the HELO command before the greeting, the message
gets delivered and it doesn't even appear in the logs. Odd for a HELO
restriction...

Putting the restrcition in smptd_recipient_restrictions (as it was in the
beginning) gives the exact same behaviour by the way...

Now I'm quite puzzled. Especially since the
http://www.postfix.org/postconf.5.html#reject_unauth_pipelining manual
says:

With Postfix 2.6 and later, the SMTP server sets a per-session flag
whenever it detects illegal pipelining, including pipelined EHLO or HELO
commands. The reject_unauth_pipelining feature simply tests whether the flag
was set at any point in time during the session.

Or am I misunderstanding something?

I'm using postfix 2.8.3 btw.

Regards

ricardus
--
View this message in context:
http://old.nabble.com/reject_unauth_pipelining-not-working-as-I%27d-expect-%28bug-%29-tp32018797p32018797.html
Sent from the Postfix mailing list archive at Nabble.com.

Re: reject_unauth_pipelining not working as I'd expect (bug?)

2011-07-07 Thread Noel Jones

On 7/7/2011 11:20 PM, ricardus1867 wrote:
 
 Hi!
 
 While crawling trough my logs, I've noticed a couple of bots getting
 rejected because of Improper use of SMTP command pipelining because of the
 reject_unauth_pipelining in smptd_recipient_restrictions. So I decided to
 give the old sleep trick a try. Only for unknown hosts, ofc...

Sounds as if it was working just fine before you started
mucking with it.  My first thought is broken test procedures.
 Which you don't describe.  Or improper analysis of evidence.
 Which you don't provide.

smtpd_delay_reject changes the timing of postfix restrictions.
 It is strongly recommended to leave this at the default setting.

 ...
 I'm using postfix 2.8.3 btw.

The sleep pseudo-restriction was a nice hack when nothing
better was available, but could cause more trouble than it was
worth by tying up valuable resources, and it made it too easy
to penalize everyone to catch a handful of bad actors.

Instead of sleep, use the postscreen feature in 2.8 to get the
grown-up version of improper pipelining and early talking
detection.




  -- Noel Jones

Re: reject_unauth_pipelining not working as I'd expect (bug?)

2011-07-07 Thread ricardus1867

On 7/7/2011 11:20 PM, ricardus1867 wrote:

While crawling trough my logs, I've noticed a couple of bots getting
rejected because of Improper use of SMTP command pipelining because of
the
reject_unauth_pipelining in smptd_recipient_restrictions. So I decided
to
give the old sleep trick a try. Only for unknown hosts, ofc...

Sounds as if it was working just fine before you started
mucking with it. My first thought is broken test procedures.
Which you don't describe. Or improper analysis of evidence.
Which you don't provide.

Well, yeah. It was working fine. Still does. Except for the pipelining
restriction...

Test procedure: open a telnet connection to the mail server and typing in
the commands

HELO example.com
MAIL From:
RCPT To:j...@example.com
DATA
Test
.

before the sleep expires (i.e. before getting 220 example.com ESMTP Postfix
in response).

With the suggested implementation (well, changing the sleeptime to 15 since
I can't copy and paste that fast), the message gets delivered. That's what
you meant by test procedure and analysis of evidence, right? English
ain't my first language...

smtpd_delay_reject changes the timing of postfix restrictions.
It is strongly recommended to leave this at the default setting.

I know. I leave all other restrictions in smtpd_recipient_restrictions
though, so they get delayed anyway. It's more of a curiousity how much spam
this would block since a few bots already got rejected because of improper
pipelining without sleeping...

...
I'm using postfix 2.8.3 btw.

The sleep pseudo-restriction was a nice hack when nothing
better was available, but could cause more trouble than it was
worth by tying up valuable resources, and it made it too easy
to penalize everyone to catch a handful of bad actors.

Instead of sleep, use the postscreen feature in 2.8 to get the
grown-up version of improper pipelining and early talking
detection.

I agree that there are better ways to fight spam. But I still wonder what
if and I still don't understand why postfix behaves as it does.

Btw, as I said, I only lets unknown hosts sleep. A cronjob checks every 15
minutes for IPs that successfully delivered their first message and adds
them to the known clients lists. Known (and whitelisted) clients do not
have to sleep...

Regards

ricardus
--
View this message in context:
http://old.nabble.com/reject_unauth_pipelining-not-working-as-I%27d-expect-%28bug-%29-tp32018797p32019060.html
Sent from the Postfix mailing list archive at Nabble.com.

Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ? (solved !)

2011-04-26 Thread Alexander Grüner


Hi,

just for info, it has been fixed on saturday.

postconf | grep mail_ver
mail_version = 2.5.6

rpm -qa | grep postfix
postfix-2.5.6-5.6.1

Nessus scan is fine.

Best regards,
Alexander

Postfix STARTTLS bug on SLES11 SP1 still unfixed ?

2011-04-15 Thread Alexander Grüner


Hello,

I am running SLES 11 SP1 (SuSE Linux Enterprise Server). After all 
patches are applied from standard update Novell sources it seems to me 
that STARTTLS bug is still unfixed.


postconf | grep mail_version
mail_version = 2.5.6

rpm -qa | grep postfix
postfix-devel-2.5.6-5.4.21
postfix-doc-2.5.6-5.4.21
postfix-2.5.6-5.4.21

more /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1

zypper lu
Loading repository data...
Reading installed packages...
No updates found.


A security scan with Nessus said:

Synopsis:
The remote mail service allows plaintext command injection while 
negotiating an encrypted communications channel

...
Plugin output:
Nessus sent the following two commands in a single packet :

STARTTLS\r\nRSET\r\n
And the server sent the following two responses :
220 2.0.0 Ready to start TLS
250 2.0.0 Ok


Am I doing somthing wrong in general or with my updates (it seems to 
work as far as I know) ? Should I take antoher version like this one: 
http://download.opensuse.org/repositories/server:/mail/SLE_11/x86_64/ ?


I verified this issue on another of my servers with same rseults...

Thank you for an answer in advance and best regards,
Alexander

Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?

2011-04-15 Thread Victor Duchovni

On Fri, Apr 15, 2011 at 08:57:19AM +0200, Alexander Gr?ner wrote:

 I am running SLES 11 SP1 (SuSE Linux Enterprise Server). After all patches 
 are applied from standard update Novell sources it seems to me that 
 STARTTLS bug is still unfixed.

 mail_version = 2.5.6

Unless they (SuSE) backported the fix, 2.5.6 was vulnerable.

 Nessus sent the following two commands in a single packet :

 STARTTLS\r\nRSET\r\n
 And the server sent the following two responses :
 220 2.0.0 Ready to start TLS
 250 2.0.0 Ok

This confirms the issue.

 Am I doing somthing wrong in general or with my updates (it seems to work 
 as far as I know) ? Should I take antoher version like this one: 
 http://download.opensuse.org/repositories/server:/mail/SLE_11/x86_64/ ?

 I verified this issue on another of my servers with same rseults...

 Thank you for an answer in advance and best regards,

The right forum is a SuSE support forum. The postfix-users list is for
Postfix issues, this is a fixed issue in Postfix, so getting your OS
distribution to adopt the fix is a non-Postfix issue.

This said, very few sites are vulnerable to this. Your server needs to
be patched if either:

- remote sites verify your certificate when sending email over TLS.

- roaming users submit mail via TLS (typically on port 587) and their
  MUA verifies your certificate, and don't ignore certificate verification
  failures.

If neither is the case, the fix does not resolve any security issues, since
unauthenticated TLS is still subject (more substantive) MITM attacks.

-- 
Viktor.

Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?

2011-04-15 Thread Alexander Grüner


 The right forum is a SuSE support forum.

Ok, I will go there.


Your server needs to
be patched if either:

 - remote sites verify your certificate when sending email over TLS.


This is the case on my server.

Thanks for the answer anyway :-)

Best regards,
Alexander

Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?

2011-04-15 Thread lst_hoe02


Zitat von Victor Duchovni victor.ducho...@morganstanley.com:


On Fri, Apr 15, 2011 at 08:57:19AM +0200, Alexander Gr?ner wrote:


I am running SLES 11 SP1 (SuSE Linux Enterprise Server). After all patches
are applied from standard update Novell sources it seems to me that
STARTTLS bug is still unfixed.

mail_version = 2.5.6


Unless they (SuSE) backported the fix, 2.5.6 was vulnerable.


Nessus sent the following two commands in a single packet :

STARTTLS\r\nRSET\r\n
And the server sent the following two responses :
220 2.0.0 Ready to start TLS
250 2.0.0 Ok


This confirms the issue.


Am I doing somthing wrong in general or with my updates (it seems to work
as far as I know) ? Should I take antoher version like this one:
http://download.opensuse.org/repositories/server:/mail/SLE_11/x86_64/ ?

I verified this issue on another of my servers with same rseults...

Thank you for an answer in advance and best regards,


The right forum is a SuSE support forum. The postfix-users list is for
Postfix issues, this is a fixed issue in Postfix, so getting your OS
distribution to adopt the fix is a non-Postfix issue.

This said, very few sites are vulnerable to this. Your server needs to
be patched if either:

- remote sites verify your certificate when sending email over TLS.

- roaming users submit mail via TLS (typically on port 587) and their
  MUA verifies your certificate, and don't ignore certificate  
verification

  failures.


This is the recommended submission setup and the most common MUAs  
(Thunderbird, Outlook, Evolution etc.) will not ignore certificate  
verification failures, no?

So every public submission service correctly setup is affected...

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?

2011-04-15 Thread Victor Duchovni

On Fri, Apr 15, 2011 at 12:31:18PM +0200, lst_ho...@kwsoft.de wrote:

 This is the recommended submission setup and the most common MUAs 
 (Thunderbird, Outlook, Evolution etc.) will not ignore certificate 
 verification failures, no?
 So every public submission service correctly setup is affected...

Yes, though some (or perhaps most) users will likely click through
warning dialogues when authentication fails, which means that
(SSL peer) authentication is often futile. :-(

-- 
Viktor.

Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?

2011-04-15 Thread Alexander Grüner


Hi,

just learned about http://support.novell.com/security/cve/ and 
especially http://support.novell.com/security/cve/CVE-2011-0411.html.


Just for future requests...

Answer from Novell The updates for this issue are in QA and will be 
released to the update channels in the next week.


Fine. Have a nice weekend.

Alexander

Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?

2011-04-15 Thread Victor Duchovni

On Fri, Apr 15, 2011 at 01:56:05PM +0200, Alexander Gr?ner wrote:

 Hi,

 just learned about http://support.novell.com/security/cve/ and especially 
 http://support.novell.com/security/cve/CVE-2011-0411.html.

 Just for future requests...

 Answer from Novell The updates for this issue are in QA and will be 
 released to the update channels in the next week.

Note that, while the CVE applies to and was discovered in Postfix,
there are other products in scope, in particular at least qmail, and
other servers or clients that implement starttls. It is not clear to me
that vendors (not picking on Novell or SuSE specifically) have applied
due diligence to all relevant products...

-- 
Viktor.

Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?

2011-04-15 Thread Joe


On 04/15/2011 01:58 AM, Alexander Grüner wrote:

 The right forum is a SuSE support forum.

Ok, I will go there.




The postfix shipped in SLES is usually a bit stale anyway. I typically 
grab a postfix source rpm from suse factory and rebuild it on SLES.


Here are some newish packages including source rpms you can rebuild.

http://software.opensuse.org/search?q=postfixbaseproject=SUSE%3ASLE-11lang=enexclude_debug=true

Joe

Message id not encircled with '' and ''. Bug in postfix logs?

2011-04-11 Thread Javier Amor Garcia


Hello,
 in my mail.log I have lines where the message-id is not encircled with 
'' and ''. This has broke my parsing scripts.


It seems that it only happens in the cleanup process. The messages-id 
hadn't domain portions.


In about one month, I had seen two examples of this problem.  I will 
show them just straight from the mail.log file:


mail.log.2:940:Mar 20 18:00:52 kif postfix/cleanup[15700]: 0097C3D8F3: 
message-id=5eade3eb1528ac2f59104cba582ef5e9


mail.log.2:41222:Mar 24 12:49:45 kif postfix/cleanup[808]: EFA813D790: 
message-id=468a9c3f8b21b9d8fe7af2181f4ddd99


This is a bug?


Cheers,
  Javier

Re: Message id not encircled with '' and ''. Bug in postfix logs?

2011-04-11 Thread Victor Duchovni

On Mon, Apr 11, 2011 at 05:17:22PM +0200, Javier Amor Garcia wrote:

 Hello,
  in my mail.log I have lines where the message-id is not encircled with '' 
 and ''. This has broke my parsing scripts.

 It seems that it only happens in the cleanup process. The messages-id 
 hadn't domain portions.

 In about one month, I had seen two examples of this problem.  I will show 
 them just straight from the mail.log file:

 mail.log.2:940:Mar 20 18:00:52 kif postfix/cleanup[15700]: 0097C3D8F3: 
 message-id=5eade3eb1528ac2f59104cba582ef5e9

 mail.log.2:41222:Mar 24 12:49:45 kif postfix/cleanup[808]: EFA813D790: 
 message-id=468a9c3f8b21b9d8fe7af2181f4ddd99

 This is a bug?

Postfix logs the content of the message-id header. Some messages are
more equal than others.

-- 
Viktor.

Re: Message id not encircled with '' and ''. Bug in postfix logs?

2011-04-11 Thread lst_hoe02


Zitat von Victor Duchovni victor.ducho...@morganstanley.com:


On Mon, Apr 11, 2011 at 05:17:22PM +0200, Javier Amor Garcia wrote:


Hello,
 in my mail.log I have lines where the message-id is not encircled with ''
and ''. This has broke my parsing scripts.

It seems that it only happens in the cleanup process. The messages-id
hadn't domain portions.

In about one month, I had seen two examples of this problem.  I will show
them just straight from the mail.log file:

mail.log.2:940:Mar 20 18:00:52 kif postfix/cleanup[15700]: 0097C3D8F3:
message-id=5eade3eb1528ac2f59104cba582ef5e9

mail.log.2:41222:Mar 24 12:49:45 kif postfix/cleanup[808]: EFA813D790:
message-id=468a9c3f8b21b9d8fe7af2181f4ddd99

This is a bug?


Postfix logs the content of the message-id header. Some messages are
more equal than others.


So it is a case of shit in, shit out??

Regards

Andreas






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Message id not encircled with '' and ''. Bug in postfix logs?

2011-04-11 Thread Victor Duchovni

On Mon, Apr 11, 2011 at 05:34:46PM +0200, lst_ho...@kwsoft.de wrote:

 Postfix logs the content of the message-id header. Some messages are
 more equal than others.

 So it is a case of shit in, shit out??

Postfix logs the content of the Message-Id header as received. To
determine whether a particular Message-Id header is valid, consult RFC
822/2822/5322, if not, complain to the sender. BOfH users can IGNORE
non-conformant Message-Id headers, and Postfix may (if suitably configure)
generate a new one that is conformant.

-- 
Viktor.

Re: Message id not encircled with '' and ''. Bug in postfix logs?

2011-04-11 Thread Javier Amor Garcia


Thanks for the answer. Things are clearer now.




message-id=468a9c3f8b21b9d8fe7af2181f4ddd99

This is a bug?


Postfix logs the content of the message-id header. Some messages are
more equal than others.

Error: close database /var/lib/postfix/postscreen_cache.db: No such file or directory (possible Berkeley DB bug)

2011-03-10 Thread Mark Alan

While using Postfix 2.8.1 + Ubuntu 10.10, after enabling postscreen the
system seems to be working well (sends and receives email without any
apparent problems) but has sporadic errors as shown bellow (without
any other errors or warnings).

sudo grep 'postscreen_cache.db' /var/log/syslog

Mar 10 11:02:24 mx postfix/postscreen[9697]:
cache /var/lib/postfix/postscreen_cache.db full cleanup: retained=0
dropped=0 entries
Mar 10 11:04:26 mx postfix/postscreen[9697]: close
database /var/lib/postfix/postscreen_cache.db: No such file or
directory (possible Berkeley DB bug)
Mar 10 11:12:08 mx postfix/postscreen[10135]: close
database /var/lib/postfix/postscreen_cache.db: No such file or
directory (possible Berkeley DB bug)
Mar 10 11:49:58 mx postfix/postscreen[12596]: close
database /var/lib/postfix/postscreen_cache.db: No such file or
directory (possible Berkeley DB bug)

# /var/lib/postfix/postscreen_cache.db exists and postfix
seems to be accessing it, as shown by the changing date/times in:

ls -l /var/lib/postfix/
total 32
-rw--- 1 postfix postfix   17 2011-03-10 11:06 master.lock
-rw--- 1 postfix postfix 8192 2011-03-10 11:10 postscreen_cache.db
-rw--- 1 postfix postfix 1024 2011-03-10 11:07 prng_exch
-rw--- 1 postfix postfix 8192 2011-03-10 11:07 smtpd_scache.db
-rw--- 1 postfix postfix 8192 2011-03-10 11:07 smtp_scache.db

# the berkeley modules are there too (the so.2's are links to the .so's)
ls -1 /var/spool/postfix/lib/
libnss_compat-2.12.1.so
libnss_compat.so.2
libnss_dns-2.12.1.so
libnss_dns.so.2
libnss_files-2.12.1.so
libnss_files.so.2
libnss_hesiod-2.12.1.so
libnss_hesiod.so.2
libnss_nis-2.12.1.so
libnss_nisplus-2.12.1.so
libnss_nisplus.so.2
libnss_nis.so.2

sudo postconf -n  # some sasl/tls entries were edited out
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
disable_vrfy_command = yes
fast_flush_domains = 
mail_name = ESMTPserver
mydestination = localhost.localdomain, localhost
mydomain = example.org
myhostname = mx.example.org
mynetworks = 127.0.0.0/8
mynetworks_style = host
myorigin = $mydomain
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*2, dnsbl-1.uceprotect.net*1,
b.barracudacentral.org*1 postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes
readme_directory = no
recipient_delimiter = +
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_authorized_verp_clients = $mynetworks
smtpd_banner = $myhostname ESMTP
smtpd_discard_ehlo_keywords = silent-discard, etrn
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unauth_pipelining, reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname, reject_non_fqdn_sender,
reject_unlisted_sender, reject_unknown_sender_domain
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth-client
smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
soft_bounce = yes
virtual_alias_maps = hash:/etc/postfix/virtual-alias-maps
virtual_mailbox_domains = example.org
virtual_mailbox_maps = hash:/etc/postfix/virtual-mailbox-maps
virtual_transport = dovecot


Any ideas?

r.

M.

Re: Error: close database /var/lib/postfix/postscreen_cache.db: No such file or directory (possible Berkeley DB bug)

2011-03-10 Thread Noel Jones


On 3/10/2011 6:58 AM, Mark Alan wrote:

While using Postfix 2.8.1 + Ubuntu 10.10, after enabling postscreen the
system seems to be working well (sends and receives email without any
apparent problems) but has sporadic errors as shown bellow (without
any other errors or warnings).



This has been asked and answered before.

http://tech.groups.yahoo.com/group/postfix-users/message/272609

Re: STARTTLS bug - background story

2011-03-08 Thread Stan Hoeppner

Wietse Venema put forth on 3/7/2011 2:08 PM:
 CERT/CC announces a flaw today in multiple STARTTLS implementations.
 This problem was silently fixed in Postfix 2.8 and 2.9. Updates
 for Postfix 2.[4-7] are made available via the usual channels.

Nice catch Wietse!  Normally I'd follow that with nice save, but,
unfortunately...

It is so darn easy for miscreants to phish account credentials from
Joe/Jane sixpack that I doubt [m]any would even bother trying to exploit
this STARTTLS flaw--much lower ROI than phishing.

Code up a fix for the Joe/Jane sixpack flaw and the world's citizens
will commission a bronze statue in your honor.

-- 
Stan

Re: STARTTLS bug -- [Zimbra]

2011-03-08 Thread Walter Smith

Hi there!
 
How severe this bug is?
 
I'm running few Zimbra servers and seems like it's there:
 
 
% telnet 0 25
220 myzimbra ESMTP Postfix
starttls
220 2.0.0 Ready to start TLS
 
% telnet 0 587
220 myzimbra ESMTP Postfix
starttls
220 2.0.0 Ready to start TLS
 
 
Should I disable it for now - is there particular parameter(s) within Postfix - 
seems to me it's kind of blended with regular TSL settings...
 
Thanks,
W.S.

--- On Tue, 3/8/11, Wietse Venema wie...@porcupine.org wrote:


From: Wietse Venema wie...@porcupine.org
Subject: Re: STARTTLS bug - background story
To: postfix-users@postfix.org
Date: Tuesday, March 8, 2011, 6:45 AM


Victor Duchovni:
 On Tue, Mar 08, 2011 at 12:59:15PM +1100, Brad Hards wrote:
 
  On Tue, 8 Mar 2011 07:08:09 am Wietse Venema wrote:
   This is a writeup about a flaw that I found recently, and that
   existed in multiple implementations of SMTP (Simple Mail Transfer
   Protocol) over TLS (Transport Layer Security) including my Postfix
   open source mailserver. I give an overview of the problem and its
   impact, technical background, how to find out if a server is affected,
   fixes, and draw lessons about where we can expect similar problems
   now or in the future. A time line is at the end.
 
  Thanks for the write-up. 
 
 It is a bit disappointing that very few of the potentially impacted
 vendors, and some definitely impacted vendors are yet to respond to
 the vulnerability:
 
     http://www.kb.cert.org/vuls/id/555316
 
 Some email appliance vendors are not on the list. Apart from Postfix,
 Qmail, and some large mailbox hosting providers, which are already
 fixed, the issue will likely linger in less visible products for
 some time...

It's easy enough to make the one-line change to openssl source, so
that people can check for this now if they are concerned.

I would expect that penetration test toolkits will eventually look
for starttls plaintext injection vulnerabilities.  But that may
take a while.

Publishing shame lists on the web is better done by people who
work for organizations with no commercial interest in the issue.

    Wietse

Re: STARTTLS bug -- [Zimbra]

2011-03-08 Thread Wietse Venema

Walter Smith:
 Hi there!
 ?
 How severe this bug is?

Please read the announcement, section overview and impact.
http://www.postfix.org/CVE-2011-0411.html

This is not as big a problem as it may appear to be. The reason
is that many SMTP client applications don't verify server TLS
certificates. These SMTP clients are always vulnerable to command
injection and other attacks. Their TLS sessions are only encrypted
but not protected.

Wietse

Re: STARTTLS bug -- [Zimbra]

2011-03-08 Thread Quanah Gibson-Mount




--On March 8, 2011 10:20:21 AM -0800 Walter Smith whatis...@yahoo.com 
wrote:




Hi there!

How severe this bug is?


The CVE gave it 1.39 out of a possible 180 points.  Or  2%.

It will of course be addressed in a later Zimbra release.

--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: STARTTLS bug -- [Zimbra]

2011-03-08 Thread Victor Duchovni

On Tue, Mar 08, 2011 at 06:26:47PM -0800, Quanah Gibson-Mount wrote:



 --On March 8, 2011 10:20:21 AM -0800 Walter Smith whatis...@yahoo.com 
 wrote:


 Hi there!

 How severe this bug is?

 The CVE gave it 1.39 out of a possible 180 points.  Or  2%.

 It will of course be addressed in a later Zimbra release.

Sites operating a STARTTLS submission service for MSAs that use AUTH
PLAIN, may want to upgrade if their users frequent public wifi hotspots,
... where MITM attacks are relatively easy to stage. There may well be
softer targets than port 587, but I think it is prudent to close this
gap. At least one large free mailbox provider has already fixed their
previously vulnerable submission service.

-- 
Viktor.

STARTTLS bug - background story

2011-03-07 Thread Wietse Venema

CERT/CC announces a flaw today in multiple STARTTLS implementations.
This problem was silently fixed in Postfix 2.8 and 2.9. Updates
for Postfix 2.[4-7] are made available via the usual channels.

Wietse

Plaintext injection in multiple implementations of STARTTLS
===

This is a writeup about a flaw that I found recently, and that
existed in multiple implementations of SMTP (Simple Mail Transfer
Protocol) over TLS (Transport Layer Security) including my Postfix
open source mailserver. I give an overview of the problem and its
impact, technical background, how to find out if a server is affected,
fixes, and draw lessons about where we can expect similar problems
now or in the future. A time line is at the end.

On-line information is/will be available at:
http://www.kb.cert.org/vuls/id/555316
http://www.postfix.org/CVE-2011-0411.html

Problem overview and impact
===

The TLS protocol encrypts communication and protects it against
modification by other parties. This protection exists only if a)
software is free of flaws, and b) clients verify the server's TLS
certificate, so that there can be no man in the middle (servers
usually don't verify client certificates).

The problem discussed in this writeup is caused by a software flaw.
The flaw allows an attacker to inject client commands into an SMTP
session during the unprotected plaintext SMTP protocol phase (more
on that below), such that the server will execute those commands
during the SMTP-over-TLS protocol phase when all communication is
supposed to be protected.

The injected commands could be used to steal the victim's email or
SASL (Simple Authentication and Security Layer) username and password.

This is not as big a problem as it may appear to be.  The reason
is that many SMTP client applications don't verify server TLS
certificates.  These SMTP clients are always vulnerable to command
injection and other attacks. Their TLS sessions are only encrypted
but not protected.

A similar plaintext injection flaw may exist in the way SMTP clients
handle SMTP-over-TLS server responses, but its impact is less
interesting than the server-side flaw.

SMTP is not the only protocol with a mid-session switch from plaintext
to TLS.  Other examples are POP3, IMAP, NNTP and FTP. Implementations
of these protocols may be affected by the same flaw as discussed here.

Technical background: SMTP over TLS
===

For a precise description of SMTP over TLS, see RFC 3207, on-line
at http://www.ietf.org/rfc/rfc3207.txt.

SMTP over TLS uses the same TLS protocol that is also used to encrypt
traffic between web clients and web servers.  But, there is a subtle
difference in the way TLS is used, and that makes this flaw possible.

SMTP sessions over TLS begin with an SMTP protocol handshake in
plaintext. Plaintext means no encryption (thus no privacy), and no
protection against modification (no integrity).  The plaintext
handshake is needed because SMTP has always worked this way.  Simply
skipping this plaintext phase would seriously break internet email.

During the plaintext handshake phase, the SMTP server announces
whether it is willing to use TLS. If both SMTP client and server
support TLS, the client sends a STARTTLS request to turn on TLS.
Once TLS is turned on, all further traffic is encrypted and protected
from modification.  The client and server repeat the entire SMTP
protocol handshake, and the client starts sending mail.

Demonstration
=

The problem is easy to demonstrate with a one-line change to the
OpenSSL s_client command source code (I would prefer scripting, but
having to install Perl CPAN modules and all their dependencies is
more work than downloading a .tar.gz file from openssl.org, adding
eight characters to one line, and doing ./config; make).

(The OpenSSL s_client command can make a connection to servers that
support straight TLS, SMTP over TLS, or a handful other protocols
over TLS. The demonstration here focuses on SMTP over TLS only.)

The demonstration with SMTP over TLS involves a one-line change in
the OpenSSL s_client source code (with OpenSSL 1.0.0, at line 1129
of file apps/s_client.c).

Old:BIO_printf(sbio,STARTTLS\r\n);
New:BIO_printf(sbio,STARTTLS\r\nRSET\r\n);

With this change, the s_client command sends the plaintext STARTTLS
command (let's turn on TLS) immediately followed by an RSET command
(a relatively harmless protocol reset). Both commands are sent
as plaintext in the same TCP/IP packet, and arrive together at the
server. The \r\n are the carriage-return and newline characters;
these are necessary to terminate an SMTP command.

When an SMTP server has the plaintext injection flaw, it reads the
STARTTLS command first, switches to SMTP-over-TLS mode, and only
then the server reads the RSET command.  Note, the RSET command was
transmitted during the plaintext SMTP phase when there is

Re: STARTTLS bug - background story

2011-03-07 Thread Brad Hards

On Tue, 8 Mar 2011 07:08:09 am Wietse Venema wrote:
 This is a writeup about a flaw that I found recently, and that
 existed in multiple implementations of SMTP (Simple Mail Transfer
 Protocol) over TLS (Transport Layer Security) including my Postfix
 open source mailserver. I give an overview of the problem and its
 impact, technical background, how to find out if a server is affected,
 fixes, and draw lessons about where we can expect similar problems
 now or in the future. A time line is at the end.
Thanks for the write-up. 

Brad

Re: STARTTLS bug - background story

2011-03-07 Thread Victor Duchovni

On Tue, Mar 08, 2011 at 12:59:15PM +1100, Brad Hards wrote:

 On Tue, 8 Mar 2011 07:08:09 am Wietse Venema wrote:
  This is a writeup about a flaw that I found recently, and that
  existed in multiple implementations of SMTP (Simple Mail Transfer
  Protocol) over TLS (Transport Layer Security) including my Postfix
  open source mailserver. I give an overview of the problem and its
  impact, technical background, how to find out if a server is affected,
  fixes, and draw lessons about where we can expect similar problems
  now or in the future. A time line is at the end.

 Thanks for the write-up. 

It is a bit disappointing that very few of the potentially impacted
vendors, and some definitely impacted vendors are yet to respond to
the vulnerability:

http://www.kb.cert.org/vuls/id/555316

Some email appliance vendors are not on the list. Apart from Postfix,
Qmail, and some large mailbox hosting providers, which are already
fixed, the issue will likely linger in less visible products for
some time...

-- 
Viktor.

Little bug (and resolution) in postfix-install

2011-03-04 Thread Matthieu Ambrosy

Hello all,

if you specify a non default config_directory variable when using
postfix-install script, you'll have this error :
postfix: fatal: open /etc/postfix/main.cf: No such file or directory

To solve it, in the last line of postfix-install, replace :
bin/postfix post-install $post_install_options || exit 1
by
bin/postfix -c $CONFIG_DIRECTORY post-install $post_install_options || exit
1

Regards,
Matthieu.

Re: Little bug (and resolution) in postfix-install

2011-03-04 Thread Wietse Venema

Matthieu Ambrosy:
 Hello all,
 
 if you specify a non default config_directory variable when using
 postfix-install script, you'll have this error :
 postfix: fatal: open /etc/postfix/main.cf: No such file or directory

This is not supported. It breaks local submission via /usr/sbin/sendmail,
among other things.

The supported options are:

1) Install Postfix first with default config directory, then
install a secondary instance with non-default config directory.
See MULTI_INSTANCE_README.html.

2) Build Postfix with DEF_CONFIG_DIR override. See INSTALL file.

Wietse

 To solve it, in the last line of postfix-install, replace :
 bin/postfix post-install $post_install_options || exit 1
 by
 bin/postfix -c $CONFIG_DIRECTORY post-install $post_install_options || exit
 1
 
 Regards,
 Matthieu.

Re: Little bug (and resolution) in postfix-install

2011-03-04 Thread Matthieu Ambrosy

Yeah, sendmail doesnt work anymore with other main.cf location, I noticed
that so I have removed the config_directory variable.
Thanks for the DEF_CONFIG_DIR tip.

Regards,
Matthieu.

2011/3/4 Wietse Venema wie...@porcupine.org

 Matthieu Ambrosy:
  Hello all,
 
  if you specify a non default config_directory variable when using
  postfix-install script, you'll have this error :
  postfix: fatal: open /etc/postfix/main.cf: No such file or directory

 This is not supported. It breaks local submission via /usr/sbin/sendmail,
 among other things.

 The supported options are:

 1) Install Postfix first with default config directory, then
 install a secondary instance with non-default config directory.
 See MULTI_INSTANCE_README.html.

 2) Build Postfix with DEF_CONFIG_DIR override. See INSTALL file.

Wietse

  To solve it, in the last line of postfix-install, replace :
  bin/postfix post-install $post_install_options || exit 1
  by
  bin/postfix -c $CONFIG_DIRECTORY post-install $post_install_options ||
 exit
  1
 
  Regards,
  Matthieu.

Bug when sending to invalid addess extension?

2011-02-14 Thread Matt Holgate


Hi,

Not sure if this is a bug or not, but thought I'd mention it, as I
noticed it recently when investigating an intrusion attempt (it was an
attempt to exploit this vulnerability in spamassassin-milter:
http://archives.neohapsis.com/archives/fulldisclosure/2010-03/0139.html)

I have root aliased to my own email address in /etc/aliases, but I
noticed if a message is sent with an invalid + extension, postfix
attempts to deliver the message locally to the root mailbox, ignoring
the alias (which fails, because postfix is set to deliver root mail as
'nobody').

For example, if /etc/aliases contains:

root: f...@example.com

then mails sent to 'root' and 'root+foo' get correctly forward to
f...@example.com.

However, if I send a mail to 'root+/' (which is invalid, because of the
slash), postfix gives a warning its log, but then tries to deliver it to
the local root account:

Feb 14 17:58:52 mailserver postfix/local[2614]: warning: 91C211741F7:
address with illegal extension: root+/
Feb 14 17:58:52 mailserver deliver(nobody): mkdir(/root/Maildir/cur)
failed: Permission denied
Feb 14 17:58:52 mailserver deliver(nobody): mkdir(/root/Maildir/cur)
failed: Permission denied
Feb 14 17:58:52 mailserver deliver(nobody): msgid
20110214173224.91C211741F7@mailserver: Couldn't open mailbox INBOX:
Internal error occurred. Refer to server log for more information.
[2011-02-14 17:58:52]

(which fails due to permissions).

The upshot of this is that exploit attempts for the vulnerability linked
to above result in the message end up stuck in the queue, and can never
be delivered (I guess they will eventually bounce).

I'm guessing the correct behaviour should either be to bounce the mail
or to forward it correctly to the alias address?

thanks,
Matt.

Re: Bug when sending to invalid addess extension?

2011-02-14 Thread Wietse Venema

Already fixed early 2010. You need to upgrade to Postfix 2.8 or
later. I don't know if this will be back-ported to earlier releases.

Wietse

20100422

Workaround (introduced: postfix-19990906 a.k.a. Postfix
0.8.0).  The Postfix local delivery agent did not properly
distinguish between address has no extension and address
has an extension, but the extension is invalid. In both
cases it would run only the full recipient local-part through
the alias maps.  Instead, it now drops the faulty extension
from the recipient address local-part (it would be too
error-prone to replace all tests for no extension by tests
for no valid extension.  File: local/recipient.c.

Re: serious bug with check_client_access

2010-11-06 Thread mouss


Le 05/11/2010 10:03, Vincent Lefevre a écrit :



[hash/cdb/...]

- if parent_domain_matches_subdomains contains smtpd_access: here, the
search list is
 S = ( lab1.lab2.lab3.example.com, lab2.lab3.example.com,
lab3.example.com ..., com, 1.2.3.4, 1.2.3, 1.2, 1 )
so postfix will search for each element of this set and stops as soon as a
match is found.

Testing the tld alone seems to be excluded by the access(5) man page,
which only documents domain.tld, i.e. the pattern must contain
at least one dot.


No dot required. so com is not excluded from the search list.
otherwise, hash/cdb and the like can't be used to block mail from 
*...@*.invalid for example.



  Is it an error in the man page (which could say
domain instead, like in Section Email address extension) or is
it intentional?


yes, it should be domain instead of domain.tld. you can submit a 
documentation patch;-p

Re: serious bug with check_client_access

2010-11-06 Thread mouss


Le 05/11/2010 09:48, Vincent Lefevre a écrit :

On 2010-11-04 23:36:04 -0300, Reinaldo de Carvalho wrote:

On Thu, Nov 4, 2010 at 11:13 PM, Vincent Lefevrevinc...@vinc17.net  wrote:

Yes, it will generate *some* lookups, but it doesn't say exactly
*which* lookups. That was precisely my question.

- client hostname (reverse dns hostname)
- client IP address.

OK, and mous said in that order (but maybe that's just the current
implementation, and the user shouldn't rely on the order for the
future).



Given all the compatibility efforts invested in postfix (thanks to 
Wietse and others), I doubt this will change.


That said, I believe it's better not to rely on, be it just for clarity. 
having things like


example.comrestriction_class_1
192.0.2  restriction_class_2

(with different restriction classes or results) in the same map is a 
call for trouble!


also, for IP addresses, better use cidr (I mean the map type, not a 
bottle from Normandy;-p).

Re: serious bug with check_client_access

2010-11-05 Thread Vincent Lefevre

On 2010-11-04 23:36:04 -0300, Reinaldo de Carvalho wrote:
 On Thu, Nov 4, 2010 at 11:13 PM, Vincent Lefevre vinc...@vinc17.net wrote:
  Yes, it will generate *some* lookups, but it doesn't say exactly
  *which* lookups. That was precisely my question.
 
 - client hostname (reverse dns hostname)
 - client IP address.

OK, and mous said in that order (but maybe that's just the current
implementation, and the user shouldn't rely on the order for the
future).

 if smtpd_access_maps in parent_domain_matches_subdomains.
 - compare client hostname without the first part at left by dot
 - compare client hostname without the first and the second part at
 left by dot (and recursively at the TDL)

but not with a regular expression table.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

2010-11-05 Thread Vincent Lefevre

On 2010-11-05 06:21:20 +0100, mouss wrote:
 in short, for each map, you have multiple parameters:
 - the map type
 - the search context (check_client_access, check_sender_acces, ...
 transport, virtual_alias_maps, ... etc)
 - the list of search keys
[...]

Thanks a lot for this very detailed answer. This was exactly the kind
of description I was looking for. I have only one comment:

 [hash/cdb/...]
 
 - if parent_domain_matches_subdomains contains smtpd_access: here, the
 search list is
 S = ( lab1.lab2.lab3.example.com, lab2.lab3.example.com,
 lab3.example.com ..., com, 1.2.3.4, 1.2.3, 1.2, 1 )
 so postfix will search for each element of this set and stops as soon as a
 match is found.

Testing the tld alone seems to be excluded by the access(5) man page,
which only documents domain.tld, i.e. the pattern must contain
at least one dot. Is it an error in the man page (which could say
domain instead, like in Section Email address extension) or is
it intentional?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

2010-11-05 Thread Stan Hoeppner

Vincent Lefevre put forth on 11/5/2010 4:03 AM:

 Testing the tld alone seems to be excluded by the access(5) man page,
 which only documents domain.tld, i.e. the pattern must contain
 at least one dot. Is it an error in the man page (which could say
 domain instead, like in Section Email address extension) or is
 it intentional?

If you want to block rDNS TLDs this PCRE works with check_client_access:

/^.*?(info|kr|jp|sg|qa)$/i 550 We do not accept mail from .$1 domains

You could also use this for check_sender_access, check_helo_access,
etc--it should work with any check that passes a string with .tld in it.

-- 
Stan

Re: serious bug with check_client_access

2010-11-04 Thread Покотиленко Костик

В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет:
 On 11/3/2010 10:00 PM, Vincent Lefevre wrote:
  On 2010-11-03 21:40:54 -0500, Noel Jones wrote:
  .domain.tld only works if parent_domain_matches_subdomains does NOT
  include smtpd_access maps.
 
  The man page says nothing like that. So, the documentation should be
  fixed.
 
 
 The vast majority of readers seem to interpret that section as 
 intended.  You're welcome to post a documentation patch in a 
 new thread, but I don't think the behavior or its 
 documentation has changed in ~10 years, so don't hold your breath.

Vast majority even believe in strange things...

Actually I read that section exactly like Vincent Lefevre.

I'll comment:

 The access(5) man page says:

   domain.tld
Matches domain.tld.

The  pattern  domain.tld also matches subdomains, but only
when the string smtpd_access_maps is listed in the Postfix
parent_domain_matches_subdomains   configuration  setting.
Otherwise, specify .domain.tld (note the initial  dot)  in
order to match subdomains.

I read Otherwise as If you don't like to depend on the value of
parent_domain_matches_subdomains

specify .domain.tld (note the initial  dot) in order to match
subdomains means exactly that using .domain.tld form WILL match
subdomains with no other condition.

Also regarding to what you are telling there is no difference in those
two sentences, and it's completelly unclear in what those two notation
forms differ and why author has written one idea in two sentences.

Check your English ;)

 And next time behavior doesn't match your expectations, you 
 might get more sympathy if your message starts with please 
 clarify this for me rather than serious bug.

If behavior doesn't match your expectations and also doesn't match docs
it's a bug, either in soft or in docs.

-- 
Покотиленко Костик cas...@meteor.dp.ua

Re: serious bug with check_client_access

2010-11-04 Thread Emmanuel Fusté


Le 04/11/2010 05:24, Noel Jones a écrit :

On 11/3/2010 11:07 PM, Vincent Lefevre wrote:

BTW, so, there is no way to match only subdomains (by that, I mean
all possible subdomains, but not the domain itself) without changing
parent_domain_matches_subdomains?


That's correct with indexed tables.  With regexp or pcre tables there
is no automatic subdomain search; you control the scope of the search
with your expression.

To answer your other question, when parent_domain_matches_subdomains
includes smtpd_access_maps (the default), the form .domain.tld is
never searched for. As a result, the entry is silently ignored.

  -- Noel Jones

Good to know, that is not what I expected too.
Hopefully, I generaly clear parent_domain_matches_subdomains in my 
configurations.


Emmanuel.

Re: serious bug with check_client_access

2010-11-04 Thread lst_hoe02


Zitat von Покотиленко Костик cas...@meteor.dp.ua:


В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет:

On 11/3/2010 10:00 PM, Vincent Lefevre wrote:
 On 2010-11-03 21:40:54 -0500, Noel Jones wrote:
 .domain.tld only works if parent_domain_matches_subdomains does NOT
 include smtpd_access maps.

 The man page says nothing like that. So, the documentation should be
 fixed.


The vast majority of readers seem to interpret that section as
intended.  You're welcome to post a documentation patch in a
new thread, but I don't think the behavior or its
documentation has changed in ~10 years, so don't hold your breath.


Vast majority even believe in strange things...

Actually I read that section exactly like Vincent Lefevre.

I'll comment:


The access(5) man page says:

  domain.tld
   Matches domain.tld.

   The  pattern  domain.tld also matches subdomains, but only
   when the string smtpd_access_maps is listed in the Postfix
   parent_domain_matches_subdomains   configuration  setting.
   Otherwise, specify .domain.tld (note the initial  dot)  in
   order to match subdomains.


I read Otherwise as If you don't like to depend on the value of
parent_domain_matches_subdomains


Otherwise is clearly related to the last part of the previous  
statement. If it is unclear, ask for clarification. Crying loud  
serious bug because your language interpretation is different from  
others is not helpful at all.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: serious bug with check_client_access

2010-11-04 Thread Покотиленко Костик

В Чтв, 04/11/2010 в 10:44 +0100, lst_ho...@kwsoft.de пишет:
 Zitat von Покотиленко Костик cas...@meteor.dp.ua:
 
  В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет:
  On 11/3/2010 10:00 PM, Vincent Lefevre wrote:
   On 2010-11-03 21:40:54 -0500, Noel Jones wrote:
   .domain.tld only works if parent_domain_matches_subdomains does NOT
   include smtpd_access maps.
  
   The man page says nothing like that. So, the documentation should be
   fixed.
  
 
  The vast majority of readers seem to interpret that section as
  intended.  You're welcome to post a documentation patch in a
  new thread, but I don't think the behavior or its
  documentation has changed in ~10 years, so don't hold your breath.
 
  Vast majority even believe in strange things...
 
  Actually I read that section exactly like Vincent Lefevre.
 
  I'll comment:
 
  The access(5) man page says:
 
domain.tld
 Matches domain.tld.
 
 The  pattern  domain.tld also matches subdomains, but only
 when the string smtpd_access_maps is listed in the Postfix
 parent_domain_matches_subdomains   configuration  setting.
 Otherwise, specify .domain.tld (note the initial  dot)  in
 order to match subdomains.
 
  I read Otherwise as If you don't like to depend on the value of
  parent_domain_matches_subdomains
 
 Otherwise is clearly related to the last part of the previous  
 statement. If it is unclear, ask for clarification.

Actually it's not clear to what condition the Otherwise is a conter
part. So it's being decided by a reader's logic wich differs sometimes.

I'm myself understood the actual meaning only after clarification on
this list. And, pleople would ask for clarification only if they can't
understand what is being ment, and not in case they think they
unsterstand.

Also, it's completelly unstated that .domain.tld notation doesn't work
if smtpd_access_maps is listed in parent_domain_matches_subdomains.

  Crying loud  
 serious bug because your language interpretation is different from  
 others is not helpful at all.

List subscriber classified this situation as a serious bug from it's
point of view, and I think this is correct. If you don't agree, just
reclassify it.

BTW, clear docs save much time for both, the user, the list.

So, I suggest rewritiing this paragraph as following:

The  pattern  domain.tld also matches subdomains, but only
when the string smtpd_access_maps is listed in the Postfix
parent_domain_matches_subdomains   configuration  setting.
The  pattern .domain.tld (note the initial  dot) matches
only subdomains and only when the string
smtpd_access_maps is NOT listed in the Postfix
parent_domain_matches_subdomains configuration setting,
otherwise it's ignored.

Is this correct?

-- 
Покотиленко Костик cas...@meteor.dp.ua

Re: serious bug with check_client_access

On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote:
 The access(5) man page says:
 
   domain.tld
Matches domain.tld.
 
The  pattern  domain.tld also matches subdomains, but only
when the string smtpd_access_maps is listed in the Postfix
parent_domain_matches_subdomains   configuration  setting.
Otherwise, specify .domain.tld (note the initial  dot)  in
order to match subdomains.
 
 I read Otherwise as If you don't like to depend on the value of
 parent_domain_matches_subdomains
 
 Otherwise is clearly related to the last part of the previous statement.

Yes, but it adds information in the case where smtpd_access_maps IS NOT
listed in the Postfix parent_domain_matches_subdomains configuration
setting.

The problem occurs when smtpd_access_maps IS listed in the Postfix
parent_domain_matches_subdomains configuration setting. What the
man page says in THIS case is: The pattern domain.tld also matches
subdomains where the pattern domain.tld can be .twitter.com for
instance.

I don't think there is anything wrong with my reasoning.

 If it is unclear, ask for clarification. Crying loud serious bug
 because your language interpretation is different from others is not
 helpful at all.

As for me, the documentation was clear and didn't match the observed
behavior. So, I couldn't say that it was unclear.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Documentation (was: serious bug with check_client_access)

2010-11-04 Thread Wietse Venema

Vincent Lefevre:
 On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote:
  The access(5) man page says:
  
domain.tld
 Matches domain.tld.
  
 The  pattern  domain.tld also matches subdomains, but only
 when the string smtpd_access_maps is listed in the Postfix
 parent_domain_matches_subdomains   configuration  setting.
 Otherwise, specify .domain.tld (note the initial  dot)  in
 order to match subdomains.

I can replace that Otherwise... sentence by a separate list item.

   domain.tld
  Matches domain.tld.

  The pattern domain.tld also matches subdomains, but only
  when the string smtpd_access_maps is listed in the Postfix
  parent_domain_matches_subdomains configuration setting.

   .domain.tld
  Matches subdomains of domain.tld, but only when the
  string smtpd_access_maps is not listed in the Postfix
  parent_domain_matches_subdomains configuration setting.

We can afford the space used by the extra bits.

Wietse

Re: Documentation (was: serious bug with check_client_access)

2010-11-04 Thread /dev/rob0

On Thu, Nov 04, 2010 at 10:56:57AM -0400, Wietse Venema wrote:
 Vincent Lefevre:
  On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote:
   The access(5) man page says:
   
 domain.tld
  Matches domain.tld.
   
  The  pattern  domain.tld also matches subdomains, but only
  when the string smtpd_access_maps is listed in the Postfix
  parent_domain_matches_subdomains   configuration  setting.
  Otherwise, specify .domain.tld (note the initial  dot)  in
  order to match subdomains.
 
 I can replace that Otherwise... sentence by a separate list item.
 
domain.tld
   Matches domain.tld.
 
 The pattern domain.tld also matches subdomains, but only
 when the string smtpd_access_maps is listed in the Postfix
 parent_domain_matches_subdomains configuration setting.
 
.domain.tld
 Matches subdomains of domain.tld, but only when the
 string smtpd_access_maps is not listed in the Postfix
 parent_domain_matches_subdomains configuration setting.

I like this. I think it's clearer. I, too, once misinterpreted this 
passage, and whilst it might not qualify as a postfix-users FAQ, it 
does come up regularly here.

Perhaps some more flesh could be added here as well:

parent_domain_matches_subdomains (default: see postconf -d output)
   What  Postfix  features match subdomains of domain.tld 
   automatically, instead of requiring an explicit .domain.tld 
   pattern.  This is planned backwards compatibility:  
   eventually, all Postfix features are expected to require 
   explicit .domain.tld style patterns when you really want to
   match subdomains.

Such as:

   Possible strings include debug_peer_list, fast_flush_domains, 
   mynetworks, permit_mx_backup_networks, qmqpd_authorized_clients,
   relay_domains, and smtpd_access_maps.

   Note: the leading dot .domain.tld pattern is ignored for
   features which are listed in parent_domain_matches_subdomains.


The string list is taken from my own postconf -d, are there others 
which might be used in some cases? I guess all of those except 
smtpd_access_maps would be hyperlinked; and maybe that could link to 
access.5.html.
-- 
Offlist mail to this address is discarded unless
/dev/rob0 or not-spam is in Subject: header

Re: Documentation (was: serious bug with check_client_access)

On 2010-11-04 10:28:00 -0500, /dev/rob0 wrote:
 On Thu, Nov 04, 2010 at 10:56:57AM -0400, Wietse Venema wrote:
  I can replace that Otherwise... sentence by a separate list item.
  
 domain.tld
Matches domain.tld.
  
The pattern domain.tld also matches subdomains, but only
when the string smtpd_access_maps is listed in the Postfix
parent_domain_matches_subdomains configuration setting.
  
 .domain.tld
Matches subdomains of domain.tld, but only when the
string smtpd_access_maps is not listed in the Postfix
parent_domain_matches_subdomains configuration setting.
 
 I like this. I think it's clearer. I, too, once misinterpreted this 
 passage, and whilst it might not qualify as a postfix-users FAQ, it 
 does come up regularly here.

I still think that it's a bit ambiguous, because I was seeing
.domain.tld as a subcase of domain.tld (domain being a
sequence of allowed characters including dots). Correct me if
I'm wrong (I haven't tested and don't know what postfix does
internally), but would changing the beginning by

domain.tld
   Matches domain.tld, where domain may contain dots, but
   must not start with a dot.

be what is really intended?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

2010-11-04 Thread mouss


Le 04/11/2010 05:07, Vincent Lefevre a écrit :

On 2010-11-03 22:55:59 -0500, Noel Jones wrote:

I'm so sorry you lost your twitter post.

Actually I might have lost other mail (though this is a bit unlikely)
since I was generally using an initial dot.


a good idea is to include both dotted and undotted entries:
example.comOK
.example.comOK
unless you have a reason not to do so.

if you search the archives for posts I've sent, you'll see that I always 
include both.


also, parent_domain_... is deprecated. See
http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains

The recommendation is to empty it and use dots explicitely. here:
# postconf parent_domain_matches_subdomains
parent_domain_matches_subdomains =



The access map format you're looking for is
twitter.com  OK

Thanks for the information. I've corrected the whole access file.

BTW, so, there is no way to match only subdomains (by that, I mean
all possible subdomains, but not the domain itself) without changing
parent_domain_matches_subdomains?



see above: it is recommended not to rely on parent_domain_...

otherwise, you can do whatever you want with pcre:
/\.example\.com$/OK
or with sql or ldap.



I don't currently need such a feature, but I'm asking just in case...

THREAD KILLED: Documentation (was: serious bug with check_client_access)

2010-11-04 Thread Victor Duchovni

On Thu, Nov 04, 2010 at 05:02:25PM +0100, Vincent Lefevre wrote:

 I still think that it's a bit ambiguous, because I was seeing
 .domain.tld as a subcase of domain.tld

This objection is spurious, and constitutes trolling. Please do not feed
the trolls.

For the record, elementary logic:

If there are two cases:

domain.tld

and

.domain.tld

and the documentation is not deliberately obfuscated, then the two
cases are distinct. This is clear enough.

The current informal style is more readable. There is no need for
a BNF grammar.

However, there is no point in continuing this thread. The OP has consumed
all the bandwidth he deserves and more.

-- 
Viktor.

Re: serious bug with check_client_access

On 2010-11-04 17:18:17 +0100, mouss wrote:
 otherwise, you can do whatever you want with pcre:
 /\.example\.com$/OK
 or with sql or ldap.

For pcre, the man page is not clear. It says:

  Each  pattern  is  a  regular  expression that is applied to the entire
  string being looked up. Depending on the application, that string is an
  entire  client hostname, an entire client IP address, or an entire mail
  address.

But where is it described whether the string is an entire client
hostname, an entire client IP address, or an entire mail address?

According to your example, the string is an entire client hostname.
But then, this means that one cannot match IP addresses.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

2010-11-04 Thread Stan Hoeppner

Vincent Lefevre put forth on 11/4/2010 6:04 PM:
 On 2010-11-04 17:18:17 +0100, mouss wrote:
 otherwise, you can do whatever you want with pcre:
 /\.example\.com$/OK
 or with sql or ldap.
 
 For pcre, the man page is not clear. It says:
 
   Each  pattern  is  a  regular  expression that is applied to the entire
   string being looked up. Depending on the application, that string is an
   entire  client hostname, an entire client IP address, or an entire mail
   address.
 
 But where is it described whether the string is an entire client
 hostname, an entire client IP address, or an entire mail address?

check_client_access pcre:/etc/postfix/filter.pcre
check_sender_access pcre:/etc/postfix/filter.pcre
check_recipient_access  pcre:/etc/postfix/filter.pcre

As you can see, this is defined by the smtpd_foo_restriction you target
the PCRE table with.  What is checked against the table is dependent on
the restriction used.  Read the documentation for each check_*_access
restriction above at:  http://www.postfix.org/postconf.5.html

-- 
Stan

Re: serious bug with check_client_access

On 2010-11-04 19:06:57 -0500, Stan Hoeppner wrote:
 check_client_access   pcre:/etc/postfix/filter.pcre
 check_sender_access   pcre:/etc/postfix/filter.pcre
 check_recipient_accesspcre:/etc/postfix/filter.pcre
 
 As you can see, this is defined by the smtpd_foo_restriction you target
 the PCRE table with.  What is checked against the table is dependent on
 the restriction used.  Read the documentation for each check_*_access
 restriction above at:  http://www.postfix.org/postconf.5.html

On this page, it is said:

  check_client_access type:table
Search the specified access database for the client hostname,
 ^^^
parent domains, client IP address, or networks obtained by
^
stripping least significant octets. See the access(5) manual page
for details.

And in the access(5) manual page:

 Depending on the application, that string is an entire client
 hostname, an entire client IP address, or an entire mail address.

So, which string is checked when a pcre table is used with
check_client_access? The client hostname or the client IP address?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

2010-11-04 Thread Wietse Venema

Vincent Lefevre:
 On 2010-11-04 19:06:57 -0500, Stan Hoeppner wrote:
  check_client_access pcre:/etc/postfix/filter.pcre
  check_sender_access pcre:/etc/postfix/filter.pcre
  check_recipient_access  pcre:/etc/postfix/filter.pcre
  
  As you can see, this is defined by the smtpd_foo_restriction you target
  the PCRE table with.  What is checked against the table is dependent on
  the restriction used.  Read the documentation for each check_*_access
  restriction above at:  http://www.postfix.org/postconf.5.html
 
 On this page, it is said:
 
   check_client_access type:table
 Search the specified access database for the client hostname,
  ^^^
 parent domains, client IP address, or networks obtained by
 ^
 stripping least significant octets. See the access(5) manual page
 for details.
 
 And in the access(5) manual page:
 
  Depending on the application, that string is an entire client
  hostname, an entire client IP address, or an entire mail address.
 
 So, which string is checked when a pcre table is used with
 check_client_access? The client hostname or the client IP address?

check_client_access searches the address and domain with ALL lookup
table types. It just doesn't do the substring lookups with PCRE,
REGEXP and CIDR.

Wietse

Re: serious bug with check_client_access

2010-11-04 Thread Jeroen Geilman


On 11/05/2010 01:26 AM, Vincent Lefevre wrote:

On 2010-11-04 19:06:57 -0500, Stan Hoeppner wrote:
   

check_client_access pcre:/etc/postfix/filter.pcre
check_sender_access pcre:/etc/postfix/filter.pcre
check_recipient_access  pcre:/etc/postfix/filter.pcre

As you can see, this is defined by the smtpd_foo_restriction you target
the PCRE table with.  What is checked against the table is dependent on
the restriction used.  Read the documentation for each check_*_access
restriction above at:  http://www.postfix.org/postconf.5.html
 

On this page, it is said:

   check_client_access type:table
 Search the specified access database for the client hostname,
  ^^^
 parent domains, client IP address, or networks obtained by
 ^
 stripping least significant octets. See the access(5) manual page
 for details.

And in the access(5) manual page:

  Depending on the application, that string is an entire client
  hostname, an entire client IP address, or an entire mail address.

So, which string is checked when a pcre table is used with
check_client_access? The client hostname or the client IP address?
   


*REGULAR EXPRESSION TABLES*
   This section describes how the table lookups  change  when
   the table is given in the form of regular expressions. For
   a description of regular expression lookup  table  syntax,
   see*regexp_table*(5)  http://www.postfix.org/regexp_table.5.html  
or*pcre_table*(5)  http://www.postfix.org/pcre_table.5.html.

   Each  pattern  is  a regular expression that is applied to
   the entire string being looked up. Depending on the appli-
   cation,  that  string  is  an  entire  client hostname, an
   entire client IP address, or an entire mail address. Thus,
   no  parent  domain  or  parent  network  search  is  done,
   /u...@domain/  mail addresses are not broken  up  into  their
   /user@/  and/domain/  constituent parts, nor is/user+foo/  broken
   up into/user/  and/foo/.

   Patterns are applied in the order as specified in the  ta-
   ble,  until  a  pattern  is  found that matches the search
   string.

   Actions are the same as with indexed  file  lookups,  with
   the  additional feature that parenthesized substrings from
   the pattern can be interpolated as*$1*,*$2*  and so on.


I copied the entire section detailing PCRE access matches for you, since 
you seem unable to find it.


How many domain names look like IP addresses to you ?

If check_client_access matches against both IPs and hostnames, then your 
regex table will match against both IPs and hostnames.


Also read http://www.postfix.org/pcre_table.5.html for more detail on 
PCRE maps.


--
J.

Re: serious bug with check_client_access

On 2010-11-04 20:33:11 -0400, Wietse Venema wrote:
 check_client_access searches the address and domain with ALL lookup
 table types. It just doesn't do the substring lookups with PCRE,
 REGEXP and CIDR.

If I understand correctly, there's another difference: in the default
table format, the string to be checked depends on the pattern form
(e.g. hostname for domain.tld, IP address for net.work.addr.ess), but
for pcre, both strings are checked against all patterns?

So, with pcre, if I want to check whether the IP address starts with
1.2.3, I need something like:

  /^1\.2\.3\.[0-9]+$/

because /^1\.2\.3\./ could also match hostnames (I've noticed in my
mail archives that hostnames of this form occur in practice).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

On 2010-11-05 01:38:37 +0100, Jeroen Geilman wrote:
 *REGULAR EXPRESSION TABLES*
This section describes how the table lookups  change  when
the table is given in the form of regular expressions. For
a description of regular expression lookup  table  syntax,
see*regexp_table*(5)  http://www.postfix.org/regexp_table.5.html  
 or*pcre_table*(5)  http://www.postfix.org/pcre_table.5.html.
 
Each  pattern  is  a regular expression that is applied to
the entire string being looked up. Depending on the appli-
cation,  that  string  is  an  entire  client hostname, an
entire client IP address, or an entire mail address. Thus,
no  parent  domain  or  parent  network  search  is  done,
/u...@domain/  mail addresses are not broken  up  into  their
/user@/  and/domain/  constituent parts, nor is/user+foo/  broken
up into/user/  and/foo/.
 
Patterns are applied in the order as specified in the  ta-
ble,  until  a  pattern  is  found that matches the search
string.
 
Actions are the same as with indexed  file  lookups,  with
the  additional feature that parenthesized substrings from
the pattern can be interpolated as*$1*,*$2*  and so on.
 
 
 I copied the entire section detailing PCRE access matches for you,
 since you seem unable to find it.

Useless answer. If you had read my message, you would have seen that
I quoted from it.

 How many domain names look like IP addresses to you ?
 
 If check_client_access matches against both IPs and hostnames, then your
 regex table will match against both IPs and hostnames.

This is not what the documentation says:

  Depending on the application, that string is an entire client
  hostname, an entire client IP address, or an entire mail address.
 ^^

It is said or, and or doesn't mean both. Quite the opposite.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

2010-11-04 Thread Jeroen Geilman


On 11/05/2010 01:57 AM, Vincent Lefevre wrote:

On 2010-11-05 01:38:37 +0100, Jeroen Geilman wrote:
   

*REGULAR EXPRESSION TABLES*
This section describes how the table lookups  change  when
the table is given in the form of regular expressions. For
a description of regular expression lookup  table  syntax,
see*regexp_table*(5)http://www.postfix.org/regexp_table.5.html   
or*pcre_table*(5)http://www.postfix.org/pcre_table.5.html.

Each  pattern  is  a regular expression that is applied to
the entire string being looked up. Depending on the appli-
cation,  that  string  is  an  entire  client hostname, an
entire client IP address, or an entire mail address. Thus,
no  parent  domain  or  parent  network  search  is  done,
/u...@domain/  mail addresses are not broken  up  into  their
/user@/  and/domain/  constituent parts, nor is/user+foo/  broken
up into/user/  and/foo/.

Patterns are applied in the order as specified in the  ta-
ble,  until  a  pattern  is  found that matches the search
string.

Actions are the same as with indexed  file  lookups,  with
the  additional feature that parenthesized substrings from
the pattern can be interpolated as*$1*,*$2*  and so on.


I copied the entire section detailing PCRE access matches for you,
since you seem unable to find it.
 

Useless answer. If you had read my message, you would have seen that
I quoted from it.
   


And yet you didn't understand what it says.
It bears repeating.


How many domain names look like IP addresses to you ?

If check_client_access matches against both IPs and hostnames, then your
regex table will match against both IPs and hostnames.
 

This is not what the documentation says:

   Depending on the application, that string is an entire client
   hostname, an entire client IP address, or an entire mail address.
  ^^

It is said or, and or doesn't mean both. Quite the opposite.
   



If you combine

Each  pattern  is  a regular expression that is applied to the entire string 
being looked up.


with
*
check_client_access /type:table 
http://www.postfix.org/DATABASE_README.html/*

   Search the specified access database for the client hostname, parent
   domains, client IP address, or networks obtained by stripping least
   significant octets. See the access(5)
   http://www.postfix.org/access.5.html manual page for details.

the result is as explained.

Nowhere in the entire documentation is it mentioned that a regex table 
will ONLY match a domain OR an IP address.


If it's not in the manual, then it's not supported.

--
J.

Re: serious bug with check_client_access