create /var/spool/imap/$LOGNAME/INBOX/ on the fly?

Hi folks,

I would like to use

	/var/spool/imap/$LOGNAME/INBOX/

for maildir. The "INBOX/" seems to be necessary to use the Dovecot
imap server with "LAYOUT=fs".

/etc/procmailrc says

	MAILDIR=/var/spool/imap
	DEFAULT=$MAILDIR/$LOGNAME/INBOX/

The problem is that procmail (3.22, as it can be found in Squeeze)
fails to generate the "$LOGNAME/INBOX" directory, if there is no
"$LOGNAME" directory yet. Dovecot is more clever in this case, but
of course there is no way to make sure that Dovecot runs into the
missing directory first.

Is there some hidden option or workaround or patch? What would
you suggest?

Any helpful comment would be highly appreciated.

Regards

Harri

Re: create /var/spool/imap/$LOGNAME/INBOX/ on the fly?

On Jan 5, 2010, at 10:34 AM, Harald Dunkel wrote:

> Hi folks,
> 
> I would like to use
> 
> 	/var/spool/imap/$LOGNAME/INBOX/
> 
> for maildir. The "INBOX/" seems to be necessary to use the Dovecot
> imap server with "LAYOUT=fs".
> 
> /etc/procmailrc says
> 
> 	MAILDIR=/var/spool/imap
> 	DEFAULT=$MAILDIR/$LOGNAME/INBOX/

:0
* !? [ -d $DEFAULT ]
	{
	... mkdir

Or something like that should do the trick.

Aloha,
Michael.
--

-- 
"Please have your Internet License             http://kapu.net/~mjwise/
 and Usenet Registration handy..."

Re: create /var/spool/imap/$LOGNAME/INBOX/ on the fly?

On 01/06/10 06:59, Michael J Wise wrote:
> 
> :0
> * !? [ -d $DEFAULT ]
> 	{
> 	... mkdir
> 
> Or something like that should do the trick.
> 

Many thanx. For the records:

PATH=/bin:/usr/bin
MAILDIR=/var/spool/imap
DEFAULT=$MAILDIR/$LOGNAME/INBOX/

:0 ic
* !? [ -d $MAILDIR/$LOGNAME ]
| mkdir -p $MAILDIR/$LOGNAME; chown $LOGNAME $MAILDIR/$LOGNAME

Regards

Harri

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail

Procmail and TMDA

Hi People
I have a problem with procmail and AADT, which is the link [1] and I am
not able to find a solution to this, anyone have any light to help me?

[1]. http://article.gmane.org/gmane.mail.spam.tmda.user/16668

--

-- 
Márcio Luciano Donada <mdonada at auroraalimentos dot com dot br>
Aurora Alimentos - Cooperativa Central Oeste Catarinense
Departamento de T.I.

Broken mass mailings - Delivered-To: issue

Several mass mailings have suddenly stopped working here.  Instead of
going to username <at> pinefields.com, they are going to
postmaster <at> pinefields.com.  The maings originate with Google, Yahoo, and
other groups, not from just one source.  the one common feature is the
To: field contains either something like "To: somename <at> some.other.com"
or is missing altogether.  There is a Delivered-To: field with a valid
address.  Attempts to brute force the mailings to the correct address,
by tweaking procmailrc, have failed miserably. 

Help!

Cheers,
Rick Emerson

Re: Broken mass mailings - Delivered-To: issue

At 22:39 2010-01-07 -0500, Richard B. Emerson wrote:
>Several mass mailings have suddenly stopped working here.  Instead of
>going to username <at> pinefields.com, they are going to
>postmaster <at> pinefields.com.  The maings originate with Google, Yahoo, and
>other groups, not from just one source.

Sounds rather like an MTA problem.  What does your mail.log have to say 
about it?

>There is a Delivered-To: field with a valid address.  Attempts to brute 
>force the mailings to the correct address, by tweaking procmailrc, have 
>failed miserably.

Do your procmail recipies attempt to deliver mail based on ^TO, like:

:0:
^TOsomeuser
someuser.mbx

If so, you should be aware that Delivered-To: isn't matched with that 
regexp macro, so it won't matter if there is a Delivered-To: header that 
shows the address.  IIRC, Delivered-To: is not specified in ANY RFC or 
internet standard.

>Help!

You don't provide ANY relevant log excerpts or procmail code.  Any help you 
might get is going to be pure conjecture.

---

Re: Broken mass mailings - Delivered-To: issue

At 10:39 2010-01-08 -0500, Richard B. Emerson wrote:

># Send bulk mail with DeliveredTo to the intended recipient

I've got to ask - WHY do you need to do this?  Is this in an 
/etc/procmailrc, or is it in ~/.procmailrc ?  If the message was delivered 
TO that user, why do you need to foward it to the SAME ADDRESS?  Sounds as 
if you're trying to use Procmail as an MTA, and you'll always have issues 
with that.

>:0:
>* ^Delivered-To: chris <at> pinefields.com
>* !^X-Loop: Delivered-To Forward Control
>   | formail -A "X-Loop: Delivered-To Forward Control" | \
>     $SENDMAIL -oi chris <at> pinefields.com

You're delivering to a pipeline not a file - no need to use a lockfile flag 
here.

>The message delivered to system <at> pinefields.com (the postmaster username)
>is a "forwarding loop" warning.

I'd take it that your MTA is detecting that it already received the 
message.  Perhaps the problem started with an upgrade to your MTA?

---
  Sean B. Straw / Professional Software Engineering

  Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.

Re: Broken mass mailings - Delivered-To: issue

The simple background to this problem is that mail delivery has worked
as it should for literally years.  And then the wheels fell off about
three days ago. 

While it's possible this is an MTA (sendmail here) issue, I have no idea
what caused the problem.  That is, I haven't made any changes to
sendmail or to procmail (if it ain't broke, don't fix it).  Of course,
there's a chance that a maintenance update has broken things. 

The idea was to use procmailrc to work around the problem: if there's a
Delivered-To: valid-user, then send it to that user.  Ugly and brute
force, I agree, but I'll take "works" over "elegant" right now. 

Most of the mass mailings we see do use To: and all is well with them. 
However, at least three sources rely on Delivered-To:; I'm not likely to
get Google, Yahoo, or the US Coast Guard to revamp their mailing
processes to suit me. 

See my follow-on note with log excerpts for more details.  I didn't want
to flood the list with them in an initial note if, in fact, I was asking
a common FAQ topic question. 

Cheers,
Rick Emerson

Professional Software Engineering wrote:
> At 22:39 2010-01-07 -0500, Richard B. Emerson wrote:
>> Several mass mailings have suddenly stopped working here.  Instead of
>> going to username <at> pinefields.com, they are going to
>> postmaster <at> pinefields.com.  The maings originate with Google, Yahoo, and

Re: Broken mass mailings - Delivered-To: issue

Professional Software Engineering wrote:
> At 10:39 2010-01-08 -0500, Richard B. Emerson wrote:
>
>> # Send bulk mail with DeliveredTo to the intended recipient
>
> I've got to ask - WHY do you need to do this?  Is this in an
> /etc/procmailrc, or is it in ~/.procmailrc ?  If the message was
> delivered TO that user, why do you need to foward it to the SAME
> ADDRESS?  Sounds as if you're trying to use Procmail as an MTA, and
> you'll always have issues with that.

I'm working on /etc/procmailrc (that is, the global rc, not the
user-specific rc).

Bear in mind that the To: line, in one of the problem messages, contains
an address that is not at pinefields.com (e.g.,
baba-l <at> yahoogroups.com).  In the case where the TO: is right, nothing
should happen.   However, in the case where the TO: is wrong but the
Delivered-To: is right, I want to use the address following the
delivered-to.
>
>> :0:
>> * ^Delivered-To: chris <at> pinefields.com
>> * !^X-Loop: Delivered-To Forward Control
>>   | formail -A "X-Loop: Delivered-To Forward Control" | \
>>     $SENDMAIL -oi chris <at> pinefields.com
>
> You're delivering to a pipeline not a file - no need to use a lockfile
> flag here.

Re: Broken mass mailings - Delivered-To: issue

Please reply to list. This reply is to list...

On Fri, 8 Jan 2010, Richard B. Emerson wrote:
: Actually, the example note has To: baba-l <at> yahoogroups.com not To:
: chris <at> pinefields.com...

The To header is irrelevant. Mail to this list is addressed "To:" the
list. But the *envelope* (which is captured in your system as a
header "Delivered-To:" is the real recipient.

: ... The intent of the recipe below is to take a message containing
: Delivered-To: and send it to the addressee in that header entry.

The 'Delivered-To' means it is ALREADY being delivered to that address!
Your MTA (sendmail) should have invoked procmail on behalf of the
'Delivered-To' user. And this should *not* depend on the "To:" header in
any way....

: "if X-Loop:..." is present, don't forward the It should keep a
: forwarding loop from forming.  Why this isn't the case is part of my
: problem.

Unless the forwarding loop is occurring *outside* of procmail!

: Why am I using sendmail?  Because that's the way it was set up with SuSE
: Linux 11.1, which is what I'm running here.

No, no, why are you SENDING the mail you just received, rather than
delivering it directly to the recipient's mailbox? IE: