headers
lists | 1 Dec 2003 01:09
Picon

Re: size does matter: controlling mail size/bounces size/mail box size


Joris, Peter:

>>on what type of system ? is that sort of stuff availabe on Linux ?
>> (RH7.3)
>
> absolutely
> Read the quota manpage

hmmm, just thinking here: as I'm doing v hosting with a single UID/GID, I
suspect, that might not work, with multiple v hosted domains on a single
UID/GID ?

virtual_transport = virtual
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_mailbox_limit = 10240000
virtual_minimum_uid = 5000
virtual_gid_maps = static:5000
virtual_uid_maps = static:5000

also, on the subject on keeping track of traffic throuput:

to monitor traffic usege per domain:
I guess that a job for pflogsumm ? or are there other tools for that
Permalink | Reply | 0 comments |
headers
Wietse Venema | 1 Dec 2003 01:29

Re: Message rate limit

Loic Minier:
> Wietse Venema <wietse <at> porcupine.org> - Sun, Nov 30, 2003:
> 
> > I do not understand why this would help. If the server closes the
> > connection then the client would connect again. This is how Postfix
> > already implements connection caching in the LMTP client.
> 
>  I thought I could limit smtp connections per second with the recent
>  smtpd_client_connection_count_limit. If there's no more than a message
>  in a connection, I can limit messages/s too... ;)

The correct solution is to limit the number of mail from commands
per unit time, not to limit the number of deliveries per session.

	Wietse
Permalink | Reply | 2 comments |
headers
Phil Ellett | 1 Dec 2003 02:36
Favicon

RE: Local recipient problems still !!

I don't have ANY virtual_alias_map as purely running a single domain and I
believe I need any ...

I could really do with a working example of how to use local_recipient_maps
with postfix.

-----Original Message-----
From: owner-postfix-users <at> postfix.org
[mailto:owner-postfix-users <at> postfix.org] On Behalf Of
Victor.Duchovni <at> morganstanley.com
Sent: 30 November 2003 18:18
To: Postfix Users List
Subject: RE: Local recipient problems still !!

On Sun, 30 Nov 2003, Phil Ellett wrote:

> Results of tests are as follows :-
>
> [root <at> pepper /]# echo "phil" | postmap -q -
> mysql:/etc/postfix/mysql-recipients.cf
> phil    phil
> [root <at> pepper /]# echo "madeup1234" | postmap -q -
> mysql:/etc/postfix/mysql-recipients.cf
> [root <at> pepper /]# echo "sysadmin" | postmap -q -
> mysql:/etc/postfix/mysql-recipients.cf
> sysadmin        sysadmin
> [root <at> pepper /]#
>
> Where account "phil" and "sysadmin" exist and "madeup1234" doesn't ...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Achim Altmann | 1 Dec 2003 03:00

postfix, amavisd-new over transport-maps ?


Hello,

could any help ?

I have to configure postfix with amavisd-new over transport maps

I saw only dokumentation for vscan like amavis (perl ) without the 
amavisd deamon

Best regards's an thank's for any help

Achim
Permalink | Reply | 4 comments |
headers
Liviu Daia | 1 Dec 2003 03:01
Picon

Request for comments: map chaining

    I've been pondering for a while about a mechanism that would be
the equivalent of shell pipes in the context of Postfix maps.  More
precisely, given a sequence (or "chain") of maps map1, map2, ..., mapN
and an input key, the key would be looked up in map1, the result(s) of
map1 would be looked up in map2, the result(s) of map2 would be looked
up in map3, and so on up to mapN.  The result(s) of the last lookup
(from mapN) would be the result(s) of the chain.  Should any of the maps
in the chain return "not found", the result of the chain would also be
"not found".

    My initial motivation for this was related to enhancing the
behaviour of LDAP maps, but this mechanism could be interesting in
general.  Aside from the obvious uses as "pipes", map chains would be a
clean solution for operations such as input or output quoting (thing RFC
2253 for LDAP, and SQL quoting), and result validation.  In the first
case, a pseudo-map in the chain would map unquoted to quoted strings, or
the converse.  In the second case, another pseudo-map would check the
results against some given rules, and simply kill the ones that fail the
checks.  External programs (like Perl scripts) could be used as filters
too.  There are other, even less obvious uses.

    Syntactically, the expressive "map1 | map2 | ... | mapN", while
appealing, is not acceptable because it would involve nasty code
complications (like unbound lookahead in the main.cf parser).  I suggest
the syntax

	chain:/path/to/file

where "/path/to/file" would be a plain file containing a list of maps.
This would allow map chains to be used just like other maps.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Leandro Santi | 1 Dec 2003 03:02
Picon
Favicon

Re: Queue manager unix domain socket connect() deadlock prevention.

Hi,

On Sun, Nov 30, 2003, Victor.Duchovni <at> morganstanley.com wrote:
> 
> The code below from qmgr_transport_alloc() makes connections to delivery
> agent transports:
> 
> #ifdef UNIX_DOMAIN_CONNECT_BLOCKS_FOR_ACCEPT
> #define BLOCK_MODE      NON_BLOCKING
> #define ENABLE_EVENTS   event_enable_write
> #define EVENT_HANDLER   qmgr_transport_connect
> #else
> #define BLOCK_MODE      BLOCKING
> #define ENABLE_EVENTS   event_enable_read
> #define EVENT_HANDLER   qmgr_transport_event
> #endif
> 
>     if ((stream = mail_connect(MAIL_CLASS_PRIVATE, transport->name, BLOCK_MODE)) == 0) {
>         msg_warn("connect to transport %s: %m", transport->name);
>         qmgr_transport_throttle(transport, "transport is unavailable");
>         return;
>     }
> 
> On most platforms the transport end-points are unix domain sockets.
> On most UNIX systems the connect() system call for unix domain sockets
> returns success or failure from connect() right away without blocking.
> 
> One some UNIX systems (notably Linux) the implementors of UNIX domain
> sockets have (misguidedly, but please ignore the flame bait) chosen to
> implement the connect() system call to block until the listener calls
(Continue reading)

Permalink | Reply | 6 comments |
headers
Wietse Venema | 1 Dec 2003 03:21

Re: Queue manager unix domain socket connect() deadlock prevention.

On Sun, Nov 30, 2003, Victor.Duchovni <at> morganstanley.com wrote:
> 
> The code below from qmgr_transport_alloc() makes connections to delivery
> agent transports:
> 
> #ifdef UNIX_DOMAIN_CONNECT_BLOCKS_FOR_ACCEPT
> #define BLOCK_MODE      NON_BLOCKING
> #define ENABLE_EVENTS   event_enable_write
> #define EVENT_HANDLER   qmgr_transport_connect
> #else
> #define BLOCK_MODE      BLOCKING
> #define ENABLE_EVENTS   event_enable_read
> #define EVENT_HANDLER   qmgr_transport_event
> #endif
> 
>     if ((stream = mail_connect(MAIL_CLASS_PRIVATE, transport->name, BLOCK_MODE)) == 0) {
>         msg_warn("connect to transport %s: %m", transport->name);
>         qmgr_transport_throttle(transport, "transport is unavailable");
>         return;
>     }
> 
> On most platforms the transport end-points are unix domain sockets.
> On most UNIX systems the connect() system call for unix domain sockets
> returns success or failure from connect() right away without blocking.
> 
> One some UNIX systems (notably Linux) the implementors of UNIX domain
> sockets have (misguidedly, but please ignore the flame bait) chosen to
> implement the connect() system call to block until the listener calls
> accept().
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Achim Altmann | 1 Dec 2003 03:38

Re: postfix, amavisd-new over transport-maps ?

Hello,

Kenneth Oncinian schrieb:

>Hi Achim,
>
>Amavisd-new provides excellent documentation, you can find it here:
>http://www.ijs.si/software/amavisd/#doc
>Also, its included in the source tarball.
>

Yes, but i could find how can i configure over content_filter=
but that isn't what i have to do
I have now run postfix with amavisd-new over conten_filter but i have to 
transport some mails form a local domain without amavisd-new
Yes i can config amavisd-new to bypass and so
that isn't also that what can help me

regards Achim

>
>Regards,
>Kenneth Oncinian
>
>On Monday 01 December 2003 10:00 am, Achim Altmann wrote:
>  
>
>>Hello,
>>
>>could any help ?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Victor.Duchovni | 1 Dec 2003 03:43
Favicon

Re: Queue manager unix domain socket connect() deadlock prevention.

On Sun, 30 Nov 2003, Wietse Venema wrote:

> > From POSIX it would seem that using the Linux compatitble code path on all
> > platforms (i.e. request a non-blocking connection) should work both on the
> > systems that need it and on the systems that implement synchronous
> > connect().
>
> It should work, but this needs to be verified anyway, so the change
> would even have to be operating system version dependent.
>

The NetBSD folks may put together a suitable small test program (that
emulates the queue manager and a concurrency limited set of delivery
agents). If we find enough testers to cover all supported platforms would
that be enough to make the change in a snapshot after 2.1?

Perhaps it is enough to just be aware of the issue. OS releases that
switch to block for accept() unix domain connect() semantics will deadlock
the Postfix queue manager under load. The increasing popularity of Postfix
might discourage such silliness going forward.

--

-- 
	Viktor.
Permalink | Reply | 3 comments |
headers
Victor.Duchovni | 1 Dec 2003 03:46
Favicon

Re: Queue manager unix domain socket connect() deadlock prevention.

On Sun, 30 Nov 2003, Leandro Santi wrote:

> But I'm not saying this shouldn't be done. Such a change will need lots
> of (multiplatform) testing, so Its not a trivial change. And, of course,
> if the new always-nonblocking behavior shows problematic it'd be easy to
> go back (because the current code works).
>

The risk is lower because the socket is not left non-blocking. Only the
connect() operation would be made in non-blocking mode. This said, I am
not gung-ho about changing anything, but if it were up to me, I would do
it in a post 2.1 snapshot on the basis that it is likely to not run into
any problems, and should future-proof the code against any surprises.

--

-- 
	Viktor.
Permalink | Reply | 0 comments |

Gmane