Posts by kilburn

Puntonetsvb gmail tiene su propio registro de confiabilidad de dominios e IPs y no publican esa información. Si te sucede eso pero no estás en ninguna blacklist pública y tus envíos salen con registros DKIM correctos solo te quedan dos opciones:

1. Cambia de proveedor (así tendrás una IP nueva y quizá más suerte)

2. Insiste, y asegúrate de que los usuarios marcan los correos como no spam. Al final google aprende (aunque si mandas <100 mails al día a gmail cuesta bastante que lo haga)

kurgans: me alegro de ver que sigues vivo y coleando! Espero que te vayan genial las cosas!

I think the real question nobody is really answering is "what exactly do you expect from an antispam system"?

Personally, I expect the following features:

1. Post-queue spam detection, to avoid overloads on huge spikes of incoming email.
2. Virus checking.
3. Rule-based spaminness determination, so it works even without any trained bayesian database.
4. Global (across-all-domains) bayesian classification.
5. Automated delivery of "Spam" tagged emails to a special "Spam" folder.
6. Ability to train both spam and ham emails, but only by certain users. "Random" users do not really distinguish between unsolicited bulk email and proper marketing e-mail that allow you to unsubscribe.
7. Per-user threshold score, white- and black-listing of sender email addresses

What are your expectations? Do they line up with mine or you have different requirements? Are they realistic? After answering those questions, we may be able to come up with a solution that fits most of us...

I think we should aim at dropping courier support. Now that there's a clean way to migrate all the mailboxes without any kind of information loss, there is simply no reason to stick with courier anymore. Dovecot is a superior piece of software, that can do everything courier can, plus some extra things. Further, it performs better in general (a lot better in some cases).

I opposed to a dovecot transition in the past (on the other project). The reason was simple: in there, we supported older debian versions (lenny) and other oses/distros that did not include dovecot >=1.1. Until dovecot 1.1 there was no clean way to migrate existing mailboxes, so dropping courier support would have meant unclean migrations (with already downloaded mails being downloaded again by the clients). However, this is not an issue anymore because all of the imscp's supported distros/versions *do* have dovecot > 1.1.

AFAIK, the only reason courier is still supported in imscp is because nuxwin wanted to keep courier, arguing that "he was fine with it and didn't want to change". Since this is obviously not a sound reason, and nuxwin is not around anymore, my opinion now is that we should move forward, drop courier, and try to achieve the best panel behaviour we can.

In this case, there should be at least a per-domain maximum mailbox quota limit, just like there is one for the disk space. The only thing I am speaking about here is a new limit in the hosting plans, stating the maximum cumulative quota that can be assigned to mailboxes of each domain. This is, a limit of "1Gb" should allow for either a 1Gb mailbox or 10 100Mb mailboxes, but not a 10Gb mailbox.

Additionally, the panel should let admins choose if the mail space is intended to be counted towards the disk quota or not. If it is not, then mail space is only limited by the mail quota above, and is enforced in real time by dovecot. Otherwise, the nighly script will detect disk oversize in the nighly run and disable FTP access (just as it does right now).

Anway, this has a very easy explanation: a hacker tried to exploit a recently discovered php bug when php runs as a CGI applicaiton.

If your server had been using an older (unpatched) php release, and it had been running in CGI mode, the result would be your server downloading the contents of an external file and executing if it was part of your website.

However, the URL the hacker constructed for the attack was too long for php's suoshin query lenght limit, so it stopped the request and logged the error.

Anyway, even if you did not have suoshin enabled, that would not have been a problem, for two reasons:

(1) The debian's included php was patched as soon as the php guys released a fix for this bug. If you have your system up to date, php simply doesn't contain this bug anymore.
(2) The bug only works when php is run as CGI. In imscp you can choose to run php in fastcgi mode (with mod_fcgid or mod_fastcgi) or in embedded mode (with mod_php), but not in CGI mode. This decision was made purely by performance reasons (php as CGI is SLOW because a different php interpret has to be executed for each request).

Login as any user and go to Profile -> Language. Anything you set there is just for the current user.

The easiest way to regenerate all the apache configuration files is by running the following, while logged in as root (replace imscp by ispcp with your imscp's database name. This will be "ispcp" if you migrated from ispcp using the migraton script):

At this point, you will be asked for the database's root user password. Enter it, and then:

You will even get a nice progress report on what the request manager is doing

I have heavily edited the debian's installation instructions page on the wiki (the actual steps/actions are the same, but I have included better/longer descriptions). If anyone thinks this is actually a bad change please say so. We can always roll back to the previous document.

Quote

Isnt it trouble enogh?
BeNE wrote, that he dont want to change too much on his imscp,
so I understand this not write an own php-wrapper and/or play with PHP_FCGI_CHILDREN etc. There are enough docs around.

There is no trouble at all. Simply put, you will have one (separate) cache for each process. It's not a big deal, just (a little) more work to populate those. Further, there is no point in fiddling with PHP_FCGI_CHILDREN stuff when using mod_fcgid, for the simple reason that mod_fcgid can not communicate with php's spawned children. If you set your PHP_FCGI_CHILDREN higher than imscp's default of 0, and you are using mod_fcgid, you simply tried to be too smart and got bitten by it. Any php spawned children are just sitting there without doing anything, besides wasting memory of course.

Therefore, the best possible route here is to simply install apc...

... and forget about it, which is hassle-free enough for me and does not require any panel modification.

If you want to go fancy, you can install the panel with mod_fastcgi instead (which *does* use multiple children as per the latest master version of i-mscp). However, mod_fastcgi is known to cause issues when it is in charge of spawning master php processes (as is the case without php5-fpm). Integration of php5-fpm is a task on our wishlist, but we are not rushing for it because it is only supported on debian wheezy or higher.

PS: I have spent a lot of time looking into these issues. And yes, I am the guy who chose the imscp's different defaults for the different apache modules.

Quote

I really like APC in this case, but it makes some trouble with fcgid.

What kind of trouble? I've been using mod_fcgid + apc like... forever. The only problem is that the cache is *not* shared between php-cgi process instances (even when the instances are for the same user). Aside from that, everything should work correctly...

Hey aseques,

What does "Alias and subdomains can be used as a full mail domains" mean? I mean, we've had mailboxes under aliases and subdomains forever, haven't we? How is that different?