slacky.eu

• ricevo tutto con fetchmail e passso il malloppo a procmail che smista la posta nelle mailbox stabilite. Fin qui niente di inconsueto e tutto stradocumentato...
• invio tutto impostando come "sendmail" lo stesso procmail che legge un file di configurazione ~/.procmailoutrc e smista la posta in uscita prima di inviarla. Per l'invio richiamo sendmail/esmtp attraverso una regola impostata proprio in "~/. procmailoutrc".

cat messaggio|formail -a "Date: `date -R`" -s /usr/bin/procmail -t -m /home/joe/.procmailoutrc

~/.procmailoutrc

:0:
* ^From.*mioindirizzo@gmail.com
{
        :0 c
        mioindirizzo@gmail.com

        :0
        | sendmail -t
}

:0:
*
$DEFAULT

set sendmail="/usr/bin/procmail -m /home/joe/.procmailoutrc"

set sendmail=/usr/bin/procmail -m /home/joe/.procmailoutrc

$ echo "Questa prova usa mailx esmtp e procmail in uscita"|mailx -v -r mioindirizzo@gmail.com -s 'Prova procmail in uscita con esmtp' mioindirizzo@gmail.com
procmail: Unrecognised options: "i"
Usage: procmail [-vptoY] [-f fromwhom] [parameter=value | rcfile] ...
   Or: procmail [-toY] [-f fromwhom] [-a argument] ... -d recipient ...
   Or: procmail [-ptY] [-f fromwhom] -m [parameter=value] ... rcfile [arg] ...
   Or: procmail [-toY] [-a argument] ... -z
Processing continued
procmail v3.22 2001/09/10
    Copyright (c) 1990-2001, Stephen R. van den Berg    <srb@cuci.nl>
    Copyright (c) 1997-2001, Philip A. Guenther         <guenther@sendmail.com>

Submit questions/answers to the procmail-related mailinglist by sending to:
        <procmail-users@procmail.org>

And of course, subscription and information requests for this list to:
        <procmail-users-request@procmail.org>

Locking strategies:     dotlocking, fcntl()
Default rcfile:         $HOME/.procmailrc
        It may be writable by your primary group
Your system mailbox:    /var/mail/joe

$ echo "Questa prova usa mailx esmtp e procmail in uscita"|mailx -v -r mioindirizzo@gmail.com -s 'Prova procmail in uscita con esmtp' mioindirizzo@gmail.com
Sendmail arguments: "send-mail" "-i" "-v" "-r" "mioindirizzo@gmail.com" "mioindirizzo@gmail.com"

set sendmail="/usr/bin/procmail -m /home/joe/.procmailoutrc"

$ echo "Questa prova usa mailx esmtp e procmail in uscita"|mailx -v -r mioindirizzo@gmail.com -s 'Prova procmail in uscita con esmtp' mioindirizzo@gmail.com
/usr/bin/procmail -m /home/joe/.procmailoutrc: File o directory non esistente
"/home/joe/dead.letter" 11/411
. . . message not sent.

$ cat mybin/procsendmail.sh 
#!/bin/sh

/usr/bin/procmail -m /home/joe/.procmailoutrc

set sendmail=/home/joe/mybin/procsendmail.sh

$ echo "Questa prova usa mailx esmtp e procmail in uscita"|mailx -v -r mioindirizzo@gmail.com -s 'Prova procmail in uscita con esmtp' mioindirizzo@gmail.com
procmail: [4925] Thu Aug 13 13:46:18 2015
procmail: Assigning "PATH=/bin:/sbin:/usr/bin:/usr/sbin"
procmail: Assigning "SHELL=/bin/bash"
procmail: Assigning "MAILDIR=/home/joe/Mail"
procmail: Assigning "LOGFILE=/home/joe/Mail/.procmail.log"
procmail: Opening "/home/joe/Mail/.procmail.log"

1. Perchè mai, mailx non riesce ad utilizzare la direttiva "set sendmail=/usr/bin/procmail -m /home/joe/.procmailoutrc" direttamente?
2. E invece riesce a riciamare lo script contenente lo stesso comando?
3. Per quale motivo compare dal nulla quel flag "-i" passato al comando "sendmail" (nel mio caso procmail) che io non ho impostato da nessuna parte?
4. Come dovrei impostare meglio la direttiva "set sendmail=" nel ~/.mailrc senza ricorrere ad uno script esterno?

sendmail=shell-command
Alternate command for delivering messages.
Note: in addition to the expected list of
recipients, mail also passes the -i and -m,
flags to the command. Since these flags are
not appropriate to other commands, you may
have to use a shell script that strips them
from the arguments list before invoking the
desired command.

Martin Neitzel ha scritto: Hi Joe,

> set sendmail=/usr/bin/procmail -m /home/joe/.procmailoutrc

First the relevant quote from the nail(1) manpage:

sendmail
To use an alternate mail delivery system, set this option to the
full pathname of the program to use. This should be used with
care.

The idea is to give users some tweaking to make nail find the MTA binary.
For example, the classic place of sendmail(8) used to be /usr/lib/sendmail
while the more modern location is /usr/sbin/sendmail. Also, most later
alternative MTA implementations such as qmail, postfix, or exim either
grok the most important classic sendmail options in the same way or
come with a compatibility wrapper which does. nail(1) will simply
run the program you specify using the "sendmail" setting and provide
it with further options and arguments (such as "-i").

As the manual says: you can just spec the pathname; no additional
options.

Providing a shell script as you did is fine. It allows you to
invoke whatever you like with whatever options. However, you
must take care that nail still invokes your script with the
original options, and those may well signify special actions.

For example, the "-i" means to sendmail(8):

-i Ignore dots alone on lines by themselves in incoming messages.
This should be set if you are reading data from a file.

This happens to be the default behaviour of procmail so you are safe
to just ignore this option.

You'd have to check the nail sources, though, to find out what other
options might be used in what circumstances. (Sending an email,
"forwarding" it, setting "from=" for an alternate sender address, ...)

Last remark:

Yes, you have to use quotes for any variable values with spaces in them.

set sendmail=/usr/bin/procmail -m /home/joe/.procmailoutrc

sets 3 variables:

sendmail (to the value /usr/bin/procmail), which has a specific
meaning to nail,

-m which is a funny name and has no specific meaning to nail

/home/joe/.procmailoutrc which is a funny name and has no
specific meaning to nail, again.

The latter to variables are just "set", in a boolean sense.

set sendmail="/usr/bin/procmail -m /home/joe/.procmailoutrc"

yields a single definition but, as you noticed, there's no such
"full pathname of the program to use" as would be required on your
filesystem.

Martin

set sendmail="/usr/bin/formail -s /usr/bin/procmail -t -m ~/.procmailoutrc"

Steffen Nurpmeso ha scritto: I'm adding the cents of S-nail here:

sendmail
To use an alternate mail transport agent (MTA), set this
option to the full pathname of the program to use. It may be
necessary to set sendmail-progname[415] in addition.

The MTA will be passed command line arguments from several
possible sources: from the variable sendmail-arguments[414] if
set, from the command line if given and the variable
expandargv[368] allows their use. It'll always be passed the
‘-i’ option, the option ‘-m’ only if the metoo[310] variable,
and ‘-v’ only if the verbose[344] variable are set. In con‐
junction with the -r[57] command line option S-nail may pass
‘-f‘ as well as ‘-F‘. Option processing of the MTA will be
terminated via a ‘--’ separator.

sendmail-arguments
Arguments to pass through to the Mail-Transfer-Agent can be
given via this option. The content of this variable will be
split up in a vector of arguments which will be joined onto
other possible MTA options:

set sendmail-arguments='-t -X "/tmp/my log"'

sendmail-progname
Many systems use a so-called mailwrapper(8)[538] environment
to ensure compatibility with sendmail(1)[539]. This works by
inspecting the name that was used to invoke the mail delivery
system. If this variable is set then the mailwrapper (the
program that is actually executed when calling “sendmail”)
will treat its contents as that name. The default is
‘sendmail’.

So you will never get around -i even with S-nail. I think i'll
add a *sendmail-no-default-arguments* option for v14.8.5,
hopefully coming late September.
Ciao,

--steffen

So you will never get around -i even with S-nail. I think i'll
add a *sendmail-no-default-arguments* option for v14.8.5,
hopefully coming late September.
Ciao,