Re: test emails did not arrive in postfix server (no indication in maillog )
You're right, there's one master postfix process locking it even though "postfix status" reported postfix is down. Killed it & now postifx could start & I'm beginning to get bounced mails notifications (shown below ***) chroot is disabled & I've whitelisted the sending domains Ran tcpdump nohup in background to check for SMTP connections but there's none other than one test outgoing email which probably failed as well. Does my firewall need to permit SMTP outgoing or just incoming is sufficient? 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME MAIL FROM: SIZE=1383 Delivery has failed to these recipients or groups: r...@myportaltech.com A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk. The following organization rejected your message: [202.6.163.31]. Diagnostic information for administrators: Generating server: gate2.mds.com.sg r...@myportaltech.com [202.6.163.31] #<[202.6.163.31] #5.0.0 smtp; 5.1.0 - Unknown address error 554-'5.7.1 : Relay access denied' (delivery attempts: 0)> #SMTP# Original message headers: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBAMtCXE3AqINE/2dsb2JhbACXTI88vSyFXgSPXw Received: from unknown (HELO sght02.mds.corp.int-ads) ([192.168.131.68]) by gate2.mds.com.sg with ESMTP/TLS/AES128-SHA; 17 Feb 2011 15:44:26 +0800 Received: from SGMBX02.mds.corp.int-ads ([fe80::11cd:49e0:af0f:1ba]) by sght02.mds.corp.int-ads ([::1]) with mapi id 14.01.0270.001; Thu, 17 Feb 2011 15:44:26 +0800 From: "G PO mds" To: "recipient...@myportaltech.com" CC: "r...@myportaltech.com" Subject: RE: testg tcpdump 1 Thread-Topic: testg tcpdump 1 Thread-Index: AQHLznZ/QZa8lLNf9kWxtxpo3qMWag== Date: Thu, 17 Feb 2011 07:44:25 + Message-ID: References: Accept-Language: en-US Content-Language: en-US * latest maillog * Feb 17 14:12:41 hostname postfix/smtpd[30975]: > gate2.mds.com.sg[203.126.130.164]: 554 5.7.1 : Relay access denied Feb 17 14:12:41 hostname postfix/smtpd[30975]: watchdog_pat: 0x80baf68 Feb 17 14:12:41 hostname postfix/smtpd[30975]: < gate2.mds.com.sg[203.126.130.164]: RCPT TO: Feb 17 14:12:41 hostname postfix/smtpd[30975]: extract_addr: input: < r...@myportaltech.com> Feb 17 14:12:41 hostname postfix/smtpd[30975]: smtpd_check_addr: addr= r...@myportaltech.com Feb 17 14:12:41 hostname postfix/smtpd[30975]: send attr request = rewrite Feb 17 14:12:41 hostname postfix/smtpd[30975]: send attr rule = local Feb 17 14:12:41 hostname postfix/smtpd[30975]: send attr address = r...@myportaltech.com Feb 17 14:12:41 hostname postfix/smtpd[30975]: private/rewrite socket: wanted attribute: flags Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute name: flags Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute value: 0 Feb 17 14:12:41 hostname postfix/smtpd[30975]: private/rewrite socket: wanted attribute: address Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute name: address Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute value: r...@myportaltech.com Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute value: r...@myportaltech.com Feb 17 14:12:41 hostname postfix/smtpd[30975]: private/rewrite socket: wanted attribute: (list terminator) Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute name: (end) Feb 17 14:12:41 hostname postfix/smtpd[30975]: rewrite_clnt: local: r...@myportaltech.com -> r...@myportaltech.com Feb 17 14:12:41 hostname postfix/smtpd[30975]: send attr request = resolve Feb 17 14:12:41 hostname postfix/smtpd[30975]: send attr sender = Feb 17 14:12:41 hostname postfix/smtpd[30975]: send attr address = r...@myportaltech.com Feb 17 14:12:41 hostname postfix/smtpd[30975]: private/rewrite socket: wanted attribute: flags Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute name: flags Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute value: 0 Feb 17 14:12:41 hostname postfix/smtpd[30975]: private/rewrite socket: wanted attribute: transport Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute name: transport Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute value: smtp Feb 17 14:12:41 hostname postfix/smtpd[30975]: private/rewrite socket: wanted attribute: nexthop Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute name: nexthop Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute value: myportaltech.com Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute value: myportaltech.com Feb 17 14:12:41 hostname postfix/smtpd[30975]: private/rewrite socket: wanted attribute: recipient Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute name: recipient Feb 17 14:12:41 hostname postfix/smtpd[30975]: input attribute value: r...@myport
understanding the why and the wherefore of postscreen
With an emphasis towards handling larger loads in the future, I am trying to get a grip on the advantages provided by postscreen as opposed to letting smtpd do the filtering "in situ." My skeptical side says that the same logic must be implemented to reject a client regardless of the process context, and postscreen creates additional process structure overhead (space) and additional interprocess communication overhead (time), and is therefore a net loss to system performance. My separation-of-duty side says that regardless, this overhead is small and the design is cleaner, allowing for more screening complexity with interesting rules that reject earlier in the SMTP conversation. My skeptical side replies that these rules could still exist in the smtpd configuration grammar. My optimization side says that parallelism can still be leveraged both on a hardware basis, as postscreen is doing logic on a new cluster of connections while smtpd is doing logic on an existing cluster, and on an I/O blocking basis, as postscreen can be waiting for (multiple, differently speeded) smtp client introductions while smtpd can focus on I/O heavy DATA transmission. My skeptical side again replies, this time arguing parallelism is relatively low given that network speeds are much slower than CPU processing speeds, and that smtpd can do select() multi-plexing rather than using additional processes to avoid blocking on any one socket. Finally, my DDAUIB (don't do anything until it's broken) side says, what metrics can I measure easily to know smtpd is getting overwhelmed and it's time for Postscreen? Is there an internal connection queue length that can get too long? Without signing up for a Postfix developer course, can anyone help straighten me out, ideally in a more concise manner than my usual wordy posts. Thank you, -Daniel
Re: understanding the why and the wherefore of postscreen
Daniel Bromberg: > With an emphasis towards handling larger loads in the future, I am > trying to get a grip on the advantages provided by postscreen as opposed > to letting smtpd do the filtering "in situ." Scalability. One postscreen process can reject more zombies than 1000+ smtpd processes. Wietse
Re: test emails did not arrive in postfix server (no indication in maillog )
On Thu, 17 Feb 2011 17:15:21 +0800 sunhux G articulated: > Does my firewall need to permit SMTP outgoing or just incoming is > sufficient? Please don't top post. If you are unfamiliar with that term, Google for it. While you are at it, could you please post in plain ASCII format. There is no need for HTML. GMail has a plain text option. Regarding the port 25 firewall rule, if it is blocked outbound, how would you expect it to work correctly? Without knowing your firewall type I cannot help you any further. Personally, I use many "stateful" rules on my systems; however, that may not be suitable for your environment. -- 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 Lunatic Asylum, n.: The place where optimism most flourishes.
Re: understanding the why and the wherefore of postscreen
On Thu, 17 Feb 2011 07:10:58 -0500 (EST) Wietse Venema articulated: > Daniel Bromberg: > > With an emphasis towards handling larger loads in the future, I am > > trying to get a grip on the advantages provided by postscreen as > > opposed to letting smtpd do the filtering "in situ." > > Scalability. One postscreen process can reject more zombies > than 1000+ smtpd processes. Impressive! I did not realize that it was that efficient. -- 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: test emails did not arrive in postfix server (no indication in maillog )
Ok, sorry. Posting in plain text now. I'm using Cyberguard firewall & I heard it's stateful. It's not managed by me but by the network/security guys. So by permitting SMTP from those selected domains' SMTP gateways to my postfix server is not sufficient even if I only need to receive incoming mails from those domains & don't need to send any outgoing mails from my postfix server? Our firewall chap found from the Cyberguard logs that there's accepted SMTP traffic passing through the firewall from the SMTP gateways of those permitted domains. Does the latest maillog I posted previously help? Thanks Sun
Mailbox limit not observed
Hello, Although I'm using virtual_mailbox_limit (in main.cf), it seems it's not being observed. I set it to: 314572800 (300MB), but I see our users have sometimes larger mailboxes. Should I do something more to enforce the limit? Please advise. Thanks, Nick Follows my config (postconf -n): alias_database = hash:/etc/postfix/aliases, hash:/etc/postfix/aliases.d/virtual_aliases alias_maps = hash:/etc/aliases broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 home_mailbox = Maildir/ html_directory = no inet_interfaces = all local_header_rewrite_clients = static:all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 20971520 mydestination = $myhostname, localhost.$mydomain, localhost mydomain = example.com *** edited for anonymization * myhostname = mail.example.com *** edited for anonymization * mynetworks = 10.10.0.0/16 *** edited for anonymization * myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix parent_domain_matches_subdomains = queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES recipient_canonical_maps = hash:/etc/postfix/domainrecipientmap relay_domains = $mydestination sample_directory = /usr/share/doc/postfix-2.3.3/samples sender_canonical_maps = hash:/etc/postfix/domainsendermap sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject smtpd_delay_reject = yes smtpd_recipient_restrictions = hash:/etc/postfix/protected_destinations,permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination smtpd_restriction_classes = allowed_list1 smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_login_maps = hash:/etc/postfix/mailloginmap smtpd_tls_CAfile = /etc/pki/tls/certs/chain-180.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/pki/tls/certs/cert-180.pem smtpd_tls_key_file = /etc/pki/tls/private/key.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/aliases, hash:/etc/postfix/aliases.d/virtual_aliases, ldap:/etc/postfix/ldap-alias-vacation.cf, ldap:/etc/postfix/ldap-aliases.cf virtual_gid_maps = static:500 virtual_mailbox_base = /home/vmail/ virtual_mailbox_domains = $mydomain,admin.$mydomain,tech.$mydomain virtual_mailbox_limit = 314572800 virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf virtual_uid_maps = static:500
Re: Mailbox limit not observed
Nikolaos Milas: > Hello, > > Although I'm using virtual_mailbox_limit (in main.cf), it seems it's not > being observed. I set it to: 314572800 (300MB), but I see our users have > sometimes larger mailboxes. There is no virtual_mailbox_limit in Postfix. It is a third-party patch. Wietse
Re: Mailbox limit not observed
Nikolaos Milas: > Hello, > > Although I'm using virtual_mailbox_limit (in main.cf), it seems it's not > being observed. I set it to: 314572800 (300MB), but I see our users have > sometimes larger mailboxes. virtual_mailbox_limit (not the quota that I was confused with) limits the size that POSTFIX can write. USERS on the other hand can change their mailbox via other programs. Wietse
Re: Mailbox limit not observed
Thanks Witsie,
Could the use of an IMAP client program (workstation-based or web-based,
like Squirrelmail) to access the incoming ("new/" Maildir) mailbox,
somehow override the directive?
Or, what other, common tools could cause such an override?
Our users are virtual, and don't have shell or other access to the mail
server, apart from POP/IMAP to their mailboxes (we are using Dovecot 1.2).
Nick
On 17/2/2011 3:23 μμ, Wietse Venema wrote:
virtual_mailbox_limit (not the quota that I was confused with) limits
the size that POSTFIX can write. USERS on the other hand can change
their mailbox via other programs.
Wietse
Re: Mailbox limit not observed
On 2/17/2011 8:32 AM, Nikolaos Milas wrote:
Thanks Witsie,
Could the use of an IMAP client program (workstation-based or
web-based, like Squirrelmail) to access the incoming ("new/" Maildir)
mailbox, somehow override the directive?
Or, what other, common tools could cause such an override?
Our users are virtual, and don't have shell or other access to the
mail server, apart from POP/IMAP to their mailboxes (we are using
Dovecot 1.2).
Nick
On 17/2/2011 3:23 μμ, Wietse Venema wrote:
virtual_mailbox_limit (not the quota that I was confused with) limits
the size that POSTFIX can write. USERS on the other hand can change
their mailbox via other programs.
Wietse
It's not an "override". Postfix is simply not involved, when, say, a
user copies messages using a desktop IMAP MUA from a remote mailbox into
the IMAP store. No postfix process runs whatsoever relating to all those
IMAP transactions. Look into, for example, the dovecot quota module.
Personally, I find it irritatingly complex and rely on the law of
averages for my total mailbox store to be a reasonable size. Someday
I'll work it out.
http://wiki.dovecot.org/Quota
-Daniel
Re: Mailbox limit not observed
Nikolaos Milas:
> Thanks Witsie,
>
> Could the use of an IMAP client program (workstation-based or web-based,
> like Squirrelmail) to access the incoming ("new/" Maildir) mailbox,
> somehow override the directive?
As documented, virtual_mailbox_limit is a mailBOX limit not a mailDIR limit.
Wietse
Re: Mailbox limit not observed
On 2/17/2011 7:32 AM, Nikolaos Milas wrote:
Thanks Witsie,
Could the use of an IMAP client program (workstation-based or
web-based, like Squirrelmail) to access the incoming ("new/"
Maildir) mailbox, somehow override the directive?
The postfix limit is for mailBOX, not mailDIR.
The postfix limit is a simple max-file-size limit and not a
quota system. Therefore, it is not effective on multi-file
mailstores such as maildir.
To implement quotas with maildir storage, use a delivery agent
that supports quotas or use filesystem quotas.
-- Noel Jones
Re: Mailbox limit not observed
On 02/17/2011 02:47 PM, Noel Jones wrote:
On 2/17/2011 7:32 AM, Nikolaos Milas wrote:
Thanks Witsie,
Could the use of an IMAP client program (workstation-based or
web-based, like Squirrelmail) to access the incoming ("new/"
Maildir) mailbox, somehow override the directive?
The postfix limit is for mailBOX, not mailDIR.
The postfix limit is a simple max-file-size limit and not a quota
system. Therefore, it is not effective on multi-file mailstores such
as maildir.
To implement quotas with maildir storage, use a delivery agent that
supports quotas or use filesystem quotas.
-- Noel Jones
If all users are virtuals how to enforce filesystem quota ?
Re: Mailbox limit not observed
Am 17.02.2011 14:49, schrieb Frank Bonnet: > If all users are virtuals how to enforce filesystem quota? postfix is simply the wrong instance quotas should do the imap/lmtp-server as example in dbmail you have in the users table a field for max mailbox size in bytes and the dbmail-lmtp rejects messages delivered from postfix if quota is exceeded signature.asc Description: OpenPGP digital signature
Re: Mailbox limit not observed
On 2/17/2011 7:49 AM, Frank Bonnet wrote:
On 02/17/2011 02:47 PM, Noel Jones wrote:
On 2/17/2011 7:32 AM, Nikolaos Milas wrote:
Thanks Witsie,
Could the use of an IMAP client program (workstation-based or
web-based, like Squirrelmail) to access the incoming ("new/"
Maildir) mailbox, somehow override the directive?
The postfix limit is for mailBOX, not mailDIR.
The postfix limit is a simple max-file-size limit and not a
quota system. Therefore, it is not effective on multi-file
mailstores such as maildir.
To implement quotas with maildir storage, use a delivery
agent that supports quotas or use filesystem quotas.
-- Noel Jones
If all users are virtuals how to enforce filesystem quota ?
If you can't use filesystem quotas, use a delivery agent that
supports quotas such as maildrop or dovecot/deliver.
-- Noel Jones
virtual_alias_maps and X-Original-To
I have an entry in the virtual_alias_maps for a few users to be redirected to zendesk.com. zendesk requires a X-Original-To header set for some stuff to work, but it isn't added in my postfix setup. I have a basic postfix setup with dovecot for virtual delivery, but from the logs it appears dovecot is not instantiated when using virtual_alias_maps since the alias means its forwarded - because its an smtp task? It seems to make sense from this thread that [http://www.dovecot.org/list/dovecot/2011-January/056783.html] "postfix adds X-Original-To when delivering to a mailbox - which delivery via smtp/lmtp isn't.", and this one http://tech.groups.yahoo.com/group/postfix-users/message/231881 "Postfix will not add X-Original-To when forwarding mail." It seems filters were suggested to be used, but it doesn't seem a common approach. I'd appreciate some guidance on this - I am a newbie trying hard not to get too lost... Regards,adam
Re: virtual_alias_maps and X-Original-To
On Thu, Feb 17, 2011 at 05:03:04PM +, Adam Hamer wrote: > I have an entry in the virtual_alias_maps for a few users to be > redirected to zendesk.com. zendesk requires a X-Original-To header set > for some stuff to work, but it isn't added in my postfix setup. > I have a basic postfix setup with dovecot for virtual delivery, > but from the logs it appears dovecot is not instantiated when using > virtual_alias_maps since the alias means its forwarded - because its > an smtp task??? No, the aliasing is not the crux of the issue when the resulting recipient is still delivered locally, but see below. > It seems to make sense from this thread that: > > http://www.dovecot.org/list/dovecot/2011-January/056783.html > > "postfix adds X-Original-To when delivering to a mailbox > > - which delivery via smtp/lmtp isn't.", This is right, only the local(8), virtual(8) and pipe(8) (flag-dependent) prepend X-Original-To. The smtp(8) and lmtp(8) delivery agents do not prepend X-Original-To headers. > and this one: > > http://tech.groups.yahoo.com/group/postfix-users/message/231881 > > "Postfix will not add X-Original-To when forwarding mail." Yes, really when not using a delivery agent that is typically used for outbound or relay email. In the case of lmtp(8) this should perhaps be revisited at some point. > It seems filters were suggested to be used, but it doesn't seem a > common approach. I'd appreciate some guidance on this - I am a newbie > trying hard not to get too lost... Are you in fact forwarding email off-site or are you using lmtp(8) to deliver email into a Dovecot IMAP store? -- Viktor.
Re: understanding the why and the wherefore of postscreen
On Thu, Feb 17, 2011 at 07:41:04AM -0500, Jerry wrote: > > Scalability. One postscreen process can reject more zombies > > than 1000+ smtpd processes. > > Impressive! I did not realize that it was that efficient. This is easy, one smtpd(8) process handles one connection, on the other hand, one postscreen(8) process handles as many connections as the file descriptor limit imposed on the master(8) process. On modern Postfix builds that are not constrained by select(2) limitations, this limit can easily be thousands of file descriptors. Note that for white-listed IPs postscreen(8) passes the connection file-descriptor to smtpd(8), so the overhead of postscreen on connections from already known IPs is negligible. -- Viktor.
RE: virtual_alias_maps and X-Original-To
> On Thu, Feb 17, 2011 at 05:03:04PM +, Adam Hamer wrote: > > > I have an entry in the virtual_alias_maps for a few users to be > > redirected to zendesk.com. zendesk requires a X-Original-To header set > > for some stuff to work, but it isn't added in my postfix setup. > > > I have a basic postfix setup with dovecot for virtual delivery, > > but from the logs it appears dovecot is not instantiated when using > > virtual_alias_maps since the alias means its forwarded - because its > > an smtp task??? > > No, the aliasing is not the crux of the issue when the resulting recipient > is still delivered locally, but see below. > The resulting recipient is not delivered locally - it goes to zendesk.com an email 'helpdesk' system. Essentially I have a domain Y.com which points to postfix. Postfix is configure to handle it as a virtual domain with dovecot, but some aliases are set to forward say a...@y.com to zendesk.com. I'm guessing those that get forwarded have nothing to do with local/mailbox delivery agent - and hence its smtp which handles it. > > It seems to make sense from this thread that: > > > > http://www.dovecot.org/list/dovecot/2011-January/056783.html > > > > "postfix adds X-Original-To when delivering to a mailbox > > > > - which delivery via smtp/lmtp isn't.", > > This is right, only the local(8), virtual(8) and pipe(8) (flag-dependent) > prepend X-Original-To. The smtp(8) and lmtp(8) delivery agents do not > prepend X-Original-To headers. > > > and this one: > > > > http://tech.groups.yahoo.com/group/postfix-users/message/231881 > > > > "Postfix will not add X-Original-To when forwarding mail." > > Yes, really when not using a delivery agent that is typically used for > outbound or relay email. In the case of lmtp(8) this should perhaps be > revisited at some point. > So my alias is outbound mail - I don't use lmtp (sorry - should have clarified that). > > It seems filters were suggested to be used, but it doesn't seem a > > common approach. I'd appreciate some guidance on this - I am a newbie > > trying hard not to get too lost... > > Are you in fact forwarding email off-site or are you using lmtp(8) to > deliver email into a Dovecot IMAP store? > Off-site. Any ideas for which way to go to make those aliases have the X-Original-To? > -- > Viktor. Thanks,adam
Re: virtual_alias_maps and X-Original-To
On Thu, Feb 17, 2011 at 09:43:05PM +, Adam Hamer wrote: > > Are you in fact forwarding email off-site or are you using lmtp(8) to > > deliver email into a Dovecot IMAP store? > > Off-site. Any ideas for which way to go to make those aliases have > the X-Original-To? Aliasing via virtual(5) is brutally efficient. No content modification, just message routing, so the header is not added. To add an X-Original-Recipient header, messages to multiple recipients have to be split into one copy per-recipient since the header you want is recipient-specific. Since the queue file contains a single copy of the message for all recipients, such rewriting *cannot* happen on input, it can only happen on output via a delivery agent that is processing a single recipient. This means you need a custom transport for this destination that processes mail one recipient at a time and prepends the header. This can be done via an external program via pipe(8) or by modifying the source code of the smtp(8) delivery agent so that the header is added when a suitable boolean flag is set and the message has exactly one recipient. The pipe(8) approach would then re-submit the mail for outbound delivery to a different Postfix instance to avoid loops. -- Viktor.
Re: Mailbox limit not observed
Wietse, Would you have any plans to integrate in Postfix support for global AND per user mailbox quotas supporting both Maildir and MBOX? This is a frequently needed feature, as I am sure you are aware. Of course, everything is always a matter of priorities and policies for the Postfix project which we all trust, yet please allow me to publish these thoughts here; such a feature would offer mail server admins a much more robust solution to implement an often required functionality. Thanks, Nick On 17/2/2011 3:44 μμ, Wietse Venema wrote: As documented, virtual_mailbox_limit is a mailBOX limit not a mailDIR limit. Wietse
