CiviCRM Community Forums (archive)

All the dependencies of the amavisd-new package plus libsoap-lite-perl and  libmail-verp-perl.

Your best bet is to actually install the amavisd-new package and then overwrite the ‘binary’ with what we have in our repository (plus the additional config file).

Installed the suggested packages.

Just make sure you also have libsoap-lite-perl and libmail-verp-perl (these are not amavisd-new’s dependencies, but are required by CiviCRM’s version).

hardy installs amavisd-new 2.5.3 & I notice on the CiviMail setup documentation that  amavisd-new_2.4.2-6.1civimail2_all.deb seems to indicate version 2.4.2. 

Is the version mismatch a problem?  If so, how can I resolve it?

The docs are a bit outdated. We now ship patched versions of AMaViS 2.4.2, 2.5.2 and 2.6.0:
http://svn.civicrm.org/civicrm/branches/v2.0/tools/amavisd-new/
http://svn.civicrm.org/civicrm/branches/v2.1/tools/amavisd-new/

Since Ubuntu Hardy is an LTS version, it seems likely to me that it will be widely installed.  Will you also patch version 2.5.3 (installed in Hardy)?

I’m finishing writing a PHP solution that should replace the patched AMaViS in CiviCRM 2.2.

I don’t think there’s much difference between AMaViS 2.5.2 and 2.5.3, so you can simply try using the 2.5.2 file in your setup.

I reopened CRM-2660 and I’ll see how much work will upgrading our patched version to 2.5.3 be.

We had not implemented CiviMail previously, although I've been using amavis-new for spam scanning on the CentOS server that I'm retiring. Will your new php based solution still "play nicely" with the usual purpose of content filtering in general?

the new solution will be based of a mailbox/imap account and will not be a content filter. So it will be similar to the imap2soap.pl script which has been community developed/supported.

lobo

Piotr-

That sounds fabulous!

Well, with 2.1 we're implementing a big expansion of Civi features into our organizational life: contributions, pledges, front-end profiles.  We're now able to use it as our "real" membership db.  So I have a lot to work on.  What that means is CiviMail can wait for your new script.

Amavis-new was only worth keeping for CiviMail.  We're on a 256Mb server and amavis is so memory hungry - almost half the ram with only two child processes.  I'll find a less resource hungry spam solution.  I really like what I'm reading about dspam at the moment.

- Shawn

Just a thought, and I posted this in another place as well, it seems to me placing optoutUrl token in the emails means the recipient can opt out by clicking a link in the email, going to the website, and opting out.

Correct.

To me this is way easier to admin then the opt out via reply in the email.

It depends. We considered dropping the SMTP actions altogether (for CiviCRM 1.9, IIRC), but the community reply was that having the SMTP counterparts – i.e., the ability to (re-,un-)subscribe and opt-out by email – was a needed feature, so we kept it.

I assume this is what the above question relates to since you do not need to do the civimail alternative install if you use this?

Well, if you do not setup the email return channel, you can’t track non-immediate bounces (the ones that happen during the initial SMTP connection, when a given email is being sent).

oh, so setting it up so soap still runs the process.

Um, did you mean cron, not SOAP here? SOAP is a way to remotely access CiviCRM; the new script will work as a part of an existing CiviCRM installation, so will just make that installation’s API calls – no SOAP necessary. (But it will have to be periodically triggered by cron.)