.forward on ISPConfig 3?

Discussion in 'General' started by DaFux, Nov 25, 2010.

  1. DaFux

    DaFux New Member

    I am running ISPConfig Since I need to process mails through a script, I'd like to use the .forward method (as described here: http://www.howtoforge.com/forums/showthread.php?t=6402).

    Although the user directories existed in ISPConfig 2 (which I liked a lot), they are gone in 3.

    So how can I solve the problem?

  2. till

    till Super Moderator Staff Member ISPConfig Developer

    The email setups of ispconfig 2 and 3 are completely different, so the method described for ispconfig 2 is not compatible with ispconfig 3.

    in ispconfig 3, you simply put the code to vredirect emails in the custom rules field of the email account. The syntax is either maildrop when courier is used or sieve when dovecot is used.
  3. DaFux

    DaFux New Member

    Thanks - I already tried that, obviously I had my syntax wrong. And probably still have, since it does not work. I have tried so far:

    to |/fullpath/myprog.php

    myprog.php has proper read/execute rights.
    Mail ist still being delivered to the inbox and not to the script...
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    The syntax you used is for procmail only.

    Do you use courier or dovecot?
  5. DaFux

    DaFux New Member

    I use courier. And thought that is maildrop (courier) syntax - I was following
    http://www.courier-mta.org/maildropfilter.html which says:

    to - deliver message to a mailbox

    to expression

    The to statement delivers the message to a mailbox. expression must evaluate to a valid mailbox. A valid mailbox is either a mailbox file, a maildir, or an external program (which includes forwarding to another address).

    The to statement is the final delivery statement. maildrop delivers message, then immediately terminates, with its return code set to the EXITCODE variable. If there was an error while delivering the message, maildrop terminates with the EX_TEMPFAIL exit code. A properly-written mail transport agent should re-queue the message, and re-attempt delivery at some later time.

    An expression that begins with the "|" character specifies an external program to run to handle the actual delivery. The SHELL variable specifies the shell to execute the given command. The message is provided to the command on standard input. maildrop's exit code will be the process's exit code.

    Any hint what would do the job properly?
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    The "to |/fullpath/myprog.php" command should work. And you are sure that your script is accessible and owned by user and group vmail?
  7. DaFux

    DaFux New Member

    Thank you, problem solved, the to-syntax finally works, no idea why it did not yesterday.
  8. DaFux

    DaFux New Member

    A little additional info about the solution for those who might be interested:

    Using courier/maildrop, the correct syntax for the custom rule is:
    to "|/full_path/scriptname.php"
    (don't forget the quotes)

    When testing, allow some time until changes made in the custom rules are active in the system (my mistake was to test immediately after making changes)

    - or -

    you can also set the filter directly in /var/vmail/mailfilters/<domain_name>/info/.mailfilter

    The script must belong to vmail, group vmail.

    When you try to call a script for example in your docroot, the call will fail with "Permission denied".

    I finally put my script into /var/vmail/<domain_name> and symlinked it my docroot (where I needed it for several reasons). That worked fine, after all.
    Last edited: Nov 26, 2010

Share This Page