Re: PostFix Trac - known issues?
* William Jordan wjor...@tninetwork.com: Hi Folks, I came across an add-on for Trac that allows tickets to be updated using mail. Email2trac is what it's called and the Postfix install is here: https://subtrac.sara.nl/oss/email2trac/wiki/Email2tracMta It has instructions on how to integrate with Postfix. I don't as yet have a specific problem but am hoping to avoid any by asking this list if anyone has done this previously and if so our their issues, caveats, best practices, or risks etc. to be concerned about? Any advise would be greatly appreciated. Looks sane to me. Be aware though, that Postfix does not allow to run mail to script commands for virtual domains (as a security precaution). In this case you need to create an alias in the virtual domain that refers to an alias in the local domain and redirect the local alias to the script. p...@rick -- All technical questions asked privately will be automatically answered on the list and archived for public access unless privacy is explicitely required and justified. saslfinger (debugging SMTP AUTH): http://postfix.state-of-mind.de/patrick.koetter/saslfinger/
Re: a little bit of help with aliases
toneeeda...@googlemail.com a écrit : Hi, Please do not top post. put your replies after the text you reply to. [snip] so i am running a virtual setup using mysql for maps. when i try to send an email to root it gets sent to r...@mail.domain.tld, since root doesn't have a domain part, postfix adds @$myorigin. by default: myorigin = $myhostname If you set myorigin = $mydomain, the root will become r...@domain.tld this email address doesnt exist, it is a local root account, so i have setup an alias in /etc/aliases which is root: external_acco...@domain.tld but this doesnt seem to be working. mail.domain.tld ($myhostname) is not listed in mydestination, so the mail won't be delivered locally, and thus /etc/aliases is not used in this case. Instead of using /etc/aliases, use virtual_alias_maps: r...@mail.domain.tldexternal_acco...@domain.tld for safety, add also: r...@domain.tld external_acco...@domain.tld (so that if you set myorigin=$mydomain, things will continue to work). PS. virtual_alias_maps apply to _all_ mail (whether local, virtual, relay and even mail destined to external domains). [snip]
Re: Postfix, mailman and procmail integration
Taylor, Marc a écrit : Good morning, I am new to this list and I am not even sure if this is the place to start, but here goes. I have an Ubuntu 8.0.4 LTS server with postfix 2.5.1-2ubuntu1.2, mailman2.1.9-9ubuntu1 and procmail3.22-16ubuntu3. I have followed the instructions in the Ubuntu community pages regarding configuring postfix, mailman and procmail to work together and I can’t seem to get mailman to pay attention to the procmail directives in /etc/procmailrcs/. mailman does not care about procmail. and both mailman and procmail are out of scope here. Is there a trick to this? Anyone else have such a setup working? Thanks! Marc Taylor
Re: Restrictions Policy Servers
Daniel L. Miller a écrit : I would like to have a policy server checked in smtpd_recipient_restrictions - but only if a previous permit_* check is true. Can I do this without coding the check within the policy server? Right now I have my standard smtpd_recipient_restrictions: smtpd_recipient_restrictions = reject_unknown_recipient_domain, reject_unverified_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, permit I would like to have the policy service executed if either permit_sasl_authenticated or permit_mynetworks is true. permit_mynetworks can be replaced by a check_client_access. for permit_sasl_authenticated, you'll have to check that in your policy server. What problem are you trying to solve? PS. It is better to use port 587 (submission) for mail submission.
Re: PostFix Trac - known issues?
Patrick Ben Koetter a écrit : * William Jordan wjor...@tninetwork.com: Hi Folks, I came across an add-on for Trac that allows tickets to be updated using mail. Email2trac is what it's called and the Postfix install is here: https://subtrac.sara.nl/oss/email2trac/wiki/Email2tracMta It has instructions on how to integrate with Postfix. I don't as yet have a specific problem but am hoping to avoid any by asking this list if anyone has done this previously and if so our their issues, caveats, best practices, or risks etc. to be concerned about? Any advise would be greatly appreciated. Looks sane to me. Be aware though, that Postfix does not allow to run mail to script commands for virtual domains (as a security precaution). In this case you need to create an alias in the virtual domain that refers to an alias in the local domain and redirect the local alias to the script. In this particular case, it is better to create a dedicated transport in master.cf (based on pipe) and use per-user transport entries.
Re: Convert _ to + on inbound addresses
LuKreme a écrit :
On 16-Jan-2010, at 12:24, Wietse Venema wrote:
To address that issue, I would like to be able to use another character
(_ or .) that is commonly accepted as part of email addresses, instead.
Address transformation mappings are always queried at recipient
validation time, so you can't use a wild-card pattern to replace
_ by + without becoming a backscatter source.
This has been covered on the list in the past (I know, I was the supplicant
last time).
I have a fairly static user list, so I managed it this way:
For local users, I have a virtual.pcre file that contains lines like:
/^kremels_(.*)@kreme.com$/kremels+${1}
for the non-local (SQL users) I have another file, virtual_sql.pcre with very
similar lines like:
/^info_(.*)@domain\.tld$/ info+$...@domain\.tld
and in main.cf I have:
virtual_alias_maps =
hash:$config_directory/virtual
pcre:$config_directory/virtual.pcre,
pcre:$config_directory/virtual_sql.pcre,
proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf
If your user list changes frequently, then this is not a really workable
solution unless you can automate the creation of the pcre files.
with SQL, there is no need to use pcre. just do that in the SQL query to
avoid having to keep an external file up to date...
mysql set @s:=foo_bar_...@example.com;
Query OK, 0 rows affected (0.00 sec)
mysql select concat(substring(@s, 1, locate(_, @s)-1), +,
substring(@s, locate(_, @s)+1)) ;
++
| concat(substring(@s, 1, locate(_, @s)-1), +, substring(@s,
locate(_, @s)+1)) |
++
| foo+bar_...@example.com
|
++
1 row in set (0.00 sec)
Re: Restrictions Policy Servers
mouss wrote: Daniel L. Miller a écrit : I would like to have a policy server checked in smtpd_recipient_restrictions - but only if a previous permit_* check is true. Can I do this without coding the check within the policy server? Right now I have my standard smtpd_recipient_restrictions: smtpd_recipient_restrictions = reject_unknown_recipient_domain, reject_unverified_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, permit I would like to have the policy service executed if either permit_sasl_authenticated or permit_mynetworks is true. permit_mynetworks can be replaced by a check_client_access. for permit_sasl_authenticated, you'll have to check that in your policy server. What problem are you trying to solve? PS. It is better to use port 587 (submission) for mail submission. I'm trying to implement an auto-whitelisting solution. I took the greylist.pl and tweaked it - and it now adds recipient addresses to a database very simply. But I only want that to happen with valid senders/clients. I was hoping there was something simple I could do to take advantage of Postfix's built-in checks without having to re-invent them or add processing time. Using port 587 is a good thought to pre-validate local senders - but I want to support verified remote senders as well - so I need a more universal solution. -- Daniel
Re: Restrictions Policy Servers
Hi, On Sun, 17.01.2010 at 09:00:13 -0800, Daniel L. Miller dmil...@amfes.com wrote: re-invent them or add processing time. Using port 587 is a good thought to pre-validate local senders - but I want to support verified remote senders as well - so I need a more universal solution. we are doing this - our users can send mail from anywhere, connecting to port 587 over TLS and using their username/password. This should be doable in Postfix, too. Kind regards, --Toni++
OT: Alternative for Spamassassin
Hi List, I`m looking for a SA replacement in an large scale enviroment. DSPAM seems to use filesystem (--with-userdir=) for various functions which is not what i want. dspam also needs per user activation. Anything except Mailstorage is placed in DB and i don`t want to change this. Does anybody know software which can replace SA and: - don`t use/need Filesystem access (except for caches and/or temp storage) - Support for 80k+ Users, Multiple node cluster - Flexible config per User (SQL Based) I`ve already read some descriptions from other projects but many of them fail on the filesystem requirement. Any ideas ? Greets Michael
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
On January 16, 2010 9:39:26 AM -0500 Wietse Venema wie...@porcupine.org wrote: Frank Cusack: until a name lookup has been done. But if that name lookup takes a very long time, along with the connect postfix should log how long ago the actual connect was. The SMTP server can find out long the name/address lookup took. Exactly my point ... and that it should (could) log that info if it took a long time, so that timestamps on logs can be more easily correlated across systems. It does not juggle TCP packets. I don't understand what you're saying here. The sysadmin should have done those name/address lookups by hand as part of due diligence, and would have observed the exact same delays that Postfix experienced. No, because typically both the resolver or intermediary (nscd et al) on the system running the lookup will cache results, as will the nameservers configured in resolv.conf. The sysadmin doing a lookup will get different timing due to being presented cached results. Even if we had TTLs of 0 (no caching; BTW not always honored by nscd type caches), differing network conditions at the time of some problem and the time of investigation could result in different name lookup delays. I amend my suggestion to say that postfix, if it wanted to log the name lookup delay, should do it *always*, not just when the delay is excessive, for consistency in the log format. -frank
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
On January 12, 2010 1:33:46 PM -0500 Victor Duchovni victor.ducho...@morganstanley.com wrote: Don't use reject_unknown_client_hostname indiscriminantly. Ironically, enough time has passed that I now received a bounce from Stan, due to my smtp host not having a PTR record. (It was a 450 and finally my smtp server gave up.) What is the reason for rejecting mail based on PTR records *at all*? It clearly doesn't confirm whether an MTA is valid* or not. -frank * not that I'm even sure what the definition of valid is.
Re: OT: Alternative for Spamassassin
* Michael Reck sir...@brauchmer.net: Hi List, I`m looking for a SA replacement in an large scale enviroment. DSPAM seems to use filesystem (--with-userdir=) for various functions which is not what i want. dspam also needs per user activation. Anything except Mailstorage is placed in DB and i don`t want to change this. Does anybody know software which can replace SA and: - don`t use/need Filesystem access (except for caches and/or temp storage) - Support for 80k+ Users, Multiple node cluster - Flexible config per User (SQL Based) Just for the books: You are aware that all your requirements can be met by Spamassassin, too. - SA can be configured to use filesystem for cache/tmp only - SA scales up to 80k+ users and more. - SA allows for SQL based rules; the config file goes into files. IIRC you can get around that too, but I am not 100% sure at the moment. How you run SA depends on how you hook it into the system. Have you considered using SA over spamass-milter? It calls the SA spamc client, which gets in contact with the SA spamd daemon. This daemon does the hard work. It can lookup user config in SQL and LDAP. Any other reasons to reject SA? p...@rick -- All technical questions asked privately will be automatically answered on the list and archived for public access unless privacy is explicitely required and justified. saslfinger (debugging SMTP AUTH): http://postfix.state-of-mind.de/patrick.koetter/saslfinger/
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
- Original Message From: Frank Cusack fcus...@fcusack.com To: postfix-users@postfix.org Sent: Sun, January 17, 2010 8:26:15 PM Subject: Re: How to not reject valid MTAs for inconsistent forward/reverse DNS. On January 12, 2010 1:33:46 PM -0500 Victor Duchovni wrote: Don't use reject_unknown_client_hostname indiscriminantly. Ironically, enough time has passed that I now received a bounce from Stan, due to my smtp host not having a PTR record. (It was a 450 and finally my smtp server gave up.) What is the reason for rejecting mail based on PTR records *at all*? It clearly doesn't confirm whether an MTA is valid* or not. -frank * not that I'm even sure what the definition of valid is. Frank, A proper ISP and Host would have the proper PTR Records set up thus validating the said sender as being part of a reputable ISP or Host. Most of the spammers I have come across have improper DNS Records set up meaning no name lookup based on IP address e.g 127.0.0.1 returns nothing. So rejecting email email by PTR Records is a spam prevention thing. At least this is my opinion. Thanks Daniel Reinhardt Website: www.cryptodan.com Email: crypto...@yahoo.com Junior Network Security Engineer
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
On January 17, 2010 12:37:46 PM -0800 Daniel V. Reinhardt crypto...@yahoo.com wrote: A proper ISP and Host would have the proper PTR Records set up thus validating the said sender as being part of a reputable ISP or Host. Most of the spammers I have come across have improper DNS Records set up meaning no name lookup based on IP address e.g 127.0.0.1 returns nothing. So rejecting email email by PTR Records is a spam prevention thing. Five years ago, yes. -frank
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
Frank Cusack put forth on 1/17/2010 2:47 PM: On January 17, 2010 12:37:46 PM -0800 Daniel V. Reinhardt crypto...@yahoo.com wrote: A proper ISP and Host would have the proper PTR Records set up thus validating the said sender as being part of a reputable ISP or Host. Most of the spammers I have come across have improper DNS Records set up meaning no name lookup based on IP address e.g 127.0.0.1 returns nothing. So rejecting email email by PTR Records is a spam prevention thing. Five years ago, yes. Have you been in prison or incapacitated for the last few years Frank? You seem to be out of touch with many established standards/norms. First you argue for multiple PTR records for mail sending hosts. Then you argue that no PTR should be required for mail sending hosts. You've just proposed both extremes of the debate, yet the debate on this was over long ago, and everyone else is right in the middle: one PTR required for a mail sending host. Rejecting mail due to lack of a PTR is an anti bot spam tactic. It is as prevalent today as it was 5 years ago, but probably less effective. Many ISPs went PTR crazy, assigning them to all their dynamic consumer IP ranges. DULs and generic PTR regexes are now more effective in this regard. Even so, there are still large amounts of consumer IP space without PTRs, so this tactic is still valid, and still widely used. -- Stan
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
Stan Hoeppner wrote: Rejecting mail due to lack of a PTR is an anti bot spam tactic. It is as prevalent today as it was 5 years ago, but probably less effective. Many ISPs went PTR crazy, assigning them to all their dynamic consumer IP ranges. DULs and generic PTR regexes are now more effective in this regard. Even so, there are still large amounts of consumer IP space without PTRs, so this tactic is still valid, and still widely used. The problem is that in countries under developpement (e.g. in Africa), there are lots of legitimate mail servers who aren't well administered (accordingly with our best practices). So rejecting messages coming from servers without PTR is a way to reject communications with these countries. It's okay if don't communicate with people from these countries. JM
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
- Original Message From: Jose-Marcio Martins da Cruz jose-marcio.mart...@ensmp.fr To: Stan Hoeppner s...@hardwarefreak.com Cc: postfix-users@postfix.org Sent: Sun, January 17, 2010 9:36:59 PM Subject: Re: How to not reject valid MTAs for inconsistent forward/reverse DNS. Stan Hoeppner wrote: Rejecting mail due to lack of a PTR is an anti bot spam tactic. It is as prevalent today as it was 5 years ago, but probably less effective. Many ISPs went PTR crazy, assigning them to all their dynamic consumer IP ranges. DULs and generic PTR regexes are now more effective in this regard. Even so, there are still large amounts of consumer IP space without PTRs, so this tactic is still valid, and still widely used. The problem is that in countries under developpement (e.g. in Africa), there are lots of legitimate mail servers who aren't well administered (accordingly with our best practices). So rejecting messages coming from servers without PTR is a way to reject communications with these countries. It's okay if don't communicate with people from these countries. JM JM, There are various online tutorials that describe how to setup a proper name server, and how to administer one. If they are unable to teach themselves, then they should get rejected till they become better educated in the practices of Information Technology and System Administration. Most of those countries you speak of setup e-mail for only one thing, and that is to propagate spam out to the world. Ever received email from a prince stating they will give you 50 Million USD if you send him 10K? If yes, then you know what I am talking about. Daniel Reinhardt Website: www.cryptodan.com Email: crypto...@yahoo.com Junior Network Security Engineer
Re: OT: Alternative for Spamassassin
Michael Reck wrote: I`m looking for a SA replacement in an large scale enviroment. DSPAM seems to use filesystem (--with-userdir=) for various functions which is not what i want. dspam also needs per user activation. Your assumptions about Dspam are wrong. Using --with-userdir is optional, and Dspam can do Optin/Optout, but this is configurable, ad depending on your setup there is no work penalty for adding new users. Anything except Mailstorage is placed in DB and i don`t want to change this. Dspam can do this with an SQL backend - Support for 80k+ Users, Multiple node cluster I have no experience with this kind of userbase, but some ppl on the dspam mailing list have ISP-sized setups running. Any ideas ? Give DSPAM a second look :) -- Regards, Tom signature.asc Description: OpenPGP digital signature
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
Daniel V. Reinhardt wrote: JM, There are various online tutorials that describe how to setup a proper name server, and how to administer one. If they are unable to teach themselves, then they should get rejected till they become better educated in the practices of Information Technology and System Administration. Most of those countries you speak of setup e-mail for only one thing, and that is to propagate spam out to the world. Ever received email from a prince stating they will give you 50 Million USD if you send him 10K? If yes, then you know what I am talking about. Sure... But have you ever maintained some communication with people from these countries ? Small companies, NGOs (non gouvernemental organisations), small schools. Sometimes, in non english talking countries their mail admins don't even talk/read english fluently and there are hardly tutorials written in their language. And they have more serious problems to handle than a perfectly defined PTR for their mail server. The environnement in these countries isn't the same as in United States, and you simply can't impose the same requirements you can impose to mail servers in USA. A good example now are mail servers in Haiti which shall probably be operating in difficult conditions. And they too are more concerned in survival than having good PTRs. You just can't reject messages coming from Haiti mailservers just because their mailservers may not have a perfectly defined PTR record. In my humble personnal opinion, I agree that we can give less priority to these servers but not just reject messages from these kind of servers. José-Marcio --
Postfix sender reputation support in snapshot 20100117
postfix-2.7-20100117 changes the meaning of content filters of the form transport: (note: no next-hop destination) so that this form can be used to implement sender reputation schemes. Typically, mail is split into classes, and all mail in class X is sent out from an SMTP client IP address that is reserved for class X. According to discussions on the Postfix list there is a legitimate need for such functionality. Until now this requires one Postfix instance per source IP address. The change introduces one minor incompatibility. As always, there is a compatibility option to restore the old behavior. This option is not needed with SMTP-based content filters, because these always have an explicit next-hop destination. With pipe-based content filters that specify no next-hop destination, the compatibility option restores the order of deliveries when a filter is congested (it restores from per-destination round-robin selection back to approximate FIFO selection). More details in the release notes quotes below. Wietse Major changes with snapshot 20100117 The FILTER action in access maps or header/body_checks now supports sender reputation schemes that dynamically choose the SMTP source IP address. This is implemented by specifying FILTER actions with empty next-hop destinations in access maps or header/body_checks, and by configuring in master.cf one Postfix SMTP client for each SMTP source IP address, where each client has its own -o myhostname and -o smtp_bind_address settings. Incompatibility with snapshot 20100117 == The meaning of an empty content filter next-hop destination has changed. Postfix now uses the recipient domain, instead of using $myhostname as in Postfix 2.6 and earlier. To get the old behavior use default_filter_nexthop = $myhostname, or specify a non-empty next-hop content filter destination.
Re: Postfix sender reputation support in snapshot 20100117
On Sun, Jan 17, 2010 at 05:38:12PM -0500, Wietse Venema wrote: According to discussions on the Postfix list there is a legitimate need for such functionality. Until now this requires one Postfix instance per source IP address. I am not entirely convinced the need is legitimate, as this probably is most useful for snow-shoe spam operations. This said, it is not clear that having snow-shoe spammers using Postfix is any worse then snow-shoe spammers using Sendmail, Qmail, Exim or various commercial engines... So long as the feature is reasonably useful to some non-spammers, we can fight spam by means more effective than trying to deny them software... -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Postfix sender reputation support in snapshot 20100117
Victor Duchovni put forth on 1/17/2010 5:43 PM: On Sun, Jan 17, 2010 at 05:38:12PM -0500, Wietse Venema wrote: According to discussions on the Postfix list there is a legitimate need for such functionality. Until now this requires one Postfix instance per source IP address. I am not entirely convinced the need is legitimate, as this probably is most useful for snow-shoe spam operations. This said, it is not clear that having snow-shoe spammers using Postfix is any worse then snow-shoe spammers using Sendmail, Qmail, Exim or various commercial engines... So long as the feature is reasonably useful to some non-spammers, we can fight spam by means more effective than trying to deny them software... I tend to agree. There are a lot of snowshoe OPs out there, and they're already using some smtp mailer engine successfully. I don't think this new feature is going to create a mad rush of spammers adopting Postfix just for this. -- Stan
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
On Jan 17, 2010, at 13:26, Frank Cusack fcus...@fcusack.com wrote: What is the reason for rejecting mail based on PTR records *at all*? Erm.… some people seem to think PTR records are required.
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
On Jan 17, 2010, at 13:37, Daniel V. Reinhardt crypto...@yahoo.com wrote: So rejecting email email by PTR Records is a spam prevention thing. Can you back this up at all? It's certainly not true in my experience and hasn't been true in a long time.
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
LuKreme put forth on 1/17/2010 5:55 PM: On Jan 17, 2010, at 13:37, Daniel V. Reinhardt crypto...@yahoo.com wrote: So rejecting email email by PTR Records is a spam prevention thing. Can you back this up at all? It's certainly not true in my experience and hasn't been true in a long time. Then I'd surmise your experience is very limited. Join spam-l and ask this naked PTR question. You will be clued. -- Stan
Re: Postfix sender reputation support in snapshot 20100117
* Wietse Venema wie...@porcupine.org: This is implemented by specifying FILTER actions with empty next-hop destinations in access maps or header/body_checks, and by configuring in master.cf one Postfix SMTP client for each SMTP source IP address, where each client has its own -o myhostname and -o smtp_bind_address settings. To be honest, I don't see what exactly has changed here. Manual pages from a stock Postfix 2.6.5: ,[ man 5 access ] | FILTER transport:destination |After the message is queued, send the entire message through the |specified external content filter. The transport:destination |syntax is described in the transport(5) manual page. ` ,[ man 5 transport ] | A non-null transport field with a null nexthop field resets the nexthop | information to the recipient domain. ` If my question is answered in other parts of the documentation, I apologize in advance. Stefan
Successful Delivery Notification
Other than scanning the logfiles, is there a way a service can receive notification of a successful delivery to a remote site? In other words, a trusted client submits mail for a remote site, Postfix connects and receives acknowledgement from the remote site, and then notifies a local process of the result? -- Daniel
The method behind the madness
I realize the developers and senior ops may be a bit irritated by some of my recent queries. I plead ignorance - and a desire to improve. I currently utilize ASSP as my primary filter. In the past, I have heard that there is nothing ASSP does that cannot be done utilizing alternative tools - in many cases built-in Postfix functionality. Regardless of your opinion of ASSP, there is a particular feature which I cannot replicate - hence my questions. That feature is auto-whitelisting. The goal is simple - there are some people businesses my company needs to correspond with no matter how strict my filter, and no matter how badly the remote site is configured. Waiting to receive a message carrying critical business information is simply unacceptable - so I need an alternative. ASSP provides me with one - by the simple act of a user sending a message to a remote, that address and/or domain is immediately whitelisted and immediately bypasses nearly all the spam filters (virus scans still occur). Daily scanning of logfiles does not accomplish this. Nor would even an hourly scan - and constant logfile scanning strikes me as inelegant. If there is any method currently existing within Postfix to accomplish this goal please point me at it! If not, I'd like to discuss possible means and methods for a future implementation. -- Daniel
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
On Jan 17, 2010, at 17:27, Stan Hoeppner s...@hardwarefreak.com wrote: Then I'd surmise your experience is very limited. I have only been running a mailserver for 17 years or so.
