procmail
[Top] [All Lists]

Re: more tweaking

1999-11-21 06:59:25
On Sun, 21 Nov 1999 05:20:47 -0800 (PST), Dallman Ross
<dman(_at_)netcom(_dot_)com> wrote:
        :0 Dch  # no lock, we're not saving anything
     * for <sat(1|2|3|4|5)@maindomain\.com>
     * for <\/sat(1|2|3|4|5)
     $MATCH

Oh, but you are. This will attempt to save to a folder whose name is
the value of the variable MATCH (in your MAILDIR, if no explicit path
name is in the value of MATCH).

First of all, I had trouble with the leading tab. I couldn't get,
for example, any of the following to match, for some reason, even
though when I examine the mail's headers there is a tab in there.
(Could my mail program be putting the tabs in on continuation
lines?)
     * ^     for <sat
     * ^[    ]for <sat
     * ^[    ]+for <sat

Right on. Procmail internally folds every header line to a single
"logical line" and so that ^ you put there is preventing these from
matching. You probably want something like this:

    * ($)[      ]for <sat

but I wouldn't be too sure that the line will always come through
folded anyhow. If you're scared of false matches, put something before
it to make sure this is only on a Received: line and roughly in the
correct context ("Received: from foo by bar for baz with SMTP id ...")

Okay, so I gave up on that and went to just looking for
     * for <sat{whatever}
as seen above.  I put the whole address in the first parse line
to be sure it was really sent to sat[1-5](_at_)maindomain(_dot_)com and not
some bogus similar thing.  Then I used a second, similar line for
the \/ stuff that $MATCH uses, but just ended after "sat[1-5]", so
that I can set $MATCH to just that, which is what I want. 
Purpose is: mail to, e.g., sat1(_at_)NOTmaindomain(_dot_)com will not
match.  But mail to sat1(_at_)maindomain(_dot_)com will match, and the
match string will be just "sat1".  This does work.  Is there a
better way?

You can grab too much and then trim it down, like this:

    :0
    * ^Received: from (.*) by (.*)[     ]for[   
]<\/sat[1-5](_at_)maindomain\(_dot_)com>
    * MATCH ?? ^^\/sat[1-5]
    { }  # no action, we do this just for the grabbing

If you need more complex grab manipulation, a more generic recipe
might look like this:

    :0  # grab sat[1-5](_at_)maindomain(_dot_)com> into MATCH
    * ^Received: from (.*) by (.*)[     ]for[   
]\/sat[1-5](_at_)maindomain\(_dot_)com>
    {
        # want "sat[1-5]" in LOCALPART and "maindomain.com" in HOSTPART

        TEMP=$MATCH

        :0  # extract from TEMP into LOCALPART
        * TEMP ?? ^^\/[^(_at_)]+
        { LOCALPART=$MATCH }

        :0  # now the same for the stuff after the @ but excluding the >
        * TEMP ?? @\/[^@<>]+
        { HOSTPART=$MATCH }

        # If you're paranoid, scream if either LOCAL or HOST is unset here
    }

This might be clearer, too; if you have trouble seeing what the
previous recipe does, try deciphering this one first. It's more
explicit although it's also more longwinded.

Okay, now to two other issues I'm running into on this 
server.  When I have a prepared message piped to sendmail
as in
     ( whatever ) | sendmail -oi -t
I get bounces.  The server says that "-oi" and "-t"
are not valid addresses.  I don't get it.  This
exact same recipe works fine on two other servers.
We're using v3.11pre7 here.  The machine is a DEC alpha.
If I use syntax like
     ! valid(_at_)address(_dot_)com
it does work, and the logs tell me that sendmail -oi -t was
invoked!  So how do I pipe stuff to sendmail in such a
situation?

Use $SENDMAIL which is what ! expands to. Probably just "sendmail"
without a path invokes some local wrapper or cheap imitation, while
$SENDMAIL with a full path invokes a different program altogether,
which is (or is better at pretending to be) a true Sendmail.

(Lots of other MTAs will install a program called "sendmail" which in
fact is an alias or wrapper for Smail or Exim or whatever you are
actually using for an MTA. Sendmail is, or used to be, so ubiquitous
that everyone else has to emulate it, even with some of its warts.)

Final problem (of this mail): fileperms are stuck
public (rwxr-xr-x) and I can't change them.  
     UMASK = 077
has absolutely no effect.  Why would that be?

Can't help with that one, I'm afraid. You should be aware that UMASK
affects the creation of new files only, though. It cannot change the
mode of a file which already exists and which you append to.

I hope I'll get more responses than I did yesterday.  :-)

One of the fundamental answers is still "don't do things this way if
you can avoid it". See <http://www.iki.fi/era/procmail/mini-faq.html>,
look for the section about virtual domains.

Hope this helps,

/* era */

-- 
 Too much to say to fit into this .signature anyway: <http://www.iki.fi/era/>
  Fight spam in Europe: <http://www.euro.cauce.org/> * Sign the EU petition

<Prev in Thread] Current Thread [Next in Thread>