headers
Arthur Dent | 2 Jun 2009 14:19
Picon
Favicon

Re: Mailchain optimisation [Long and possibly OT]

Hello Sean (and others),
Thank you for you comprehensive reply. It has given me much food for thought.
I have spent much of the weekend researching as a result. I have come to the
conclusion that I still have much to learn!

On Sat, May 30, 2009 at 08:25:35AM -0700, Professional Software Engineering wrote:
> At 13:22 2009-05-30 +0100, Arthur Dent wrote:
>
>> This is a home server. I am not a sysadmin just an interested hobbyist.
>
> You're not a sysadmin by profession - you're still a sysadmin if it's 
> your machine and you're responsible for the administration of it.

Yeah - but it's just like a real job - underpaid, overworked, under recognised
and always in trouble with the boss. Some of the fringe benefits are OK though
(I get to sleep with the client!).

>> fetchmail->procmail(->clamav->spamassassin)->dovecot
>> I use mbox format (not maildir).
>
> Ah, the fetchmail bit wasn't mentioned previously.
>
> If the host on a static (fixed, unchanging) IP, or dynamic?  If it's  
> static, there's a lot you can to to improve things, esp for the vanity  
> domain - your other domains would still be fetchmailed.

I am on a dynamic IP (it changes only - roughly - every 3 months however).

>> I have mail accounts with at least 4 different ISPs at least one of
>> which is a catch-all address. One is a vanity domain address and is of
(Continue reading)

Permalink | Reply | 2 comments |
headers
R A Lichtensteiger | 2 Jun 2009 20:11
Favicon

Re: Mailchain optimisation [Long and possibly OT]

Arthur Dent wrote:

<> > If the host on a static (fixed, unchanging) IP, or dynamic?  If it's  
<> > static, there's a lot you can to to improve things, esp for the vanity  
<> > domain - your other domains would still be fetchmailed.
<> 
<> I am on a dynamic IP (it changes only - roughly - every 3 months however).

Again, it depends on whether demon.co.uk will provide a DNS MX record
for myvanitydomain.demon.co.uk, but if they do, then you can use one
of the DNS providers like dyndns.org to provide an address record to
point the MX to.  Eg.,

  % host -t mx myvanitydomain.demon.co.uk
  myvanitydomain.demon.co.uk mail is handled by 10 myvanitydomain.dyndns.org
  % host myvanitydomain.dyndns.org
  myvanitydomain.dyndns.org has address AAA.BBB.CCC.DDD

(Mild handwaving on how the IP address gets submitted to DynDNS when
it changes owing to details such as "are you using a firewall/NAT
router on the connection" etc.)

I'll note that the demon.co.uk (demon.net) FAQ pages specify that:

  Can I direct my mail to somewhere other than the RaQ?

  You are free to point (or have us point) your primary MX record(s)
  at a mail server of your choosing [...]

http://www.demon.net/helpdesk/producthelp/serverhosting/faq/tech-domain.html#idirect
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Wellings | 2 Jun 2009 21:51
Picon

Re: Mailchain optimisation [Long and possibly OT]

On Tue, 02 Jun 2009, Arthur Dent wrote:

>  
> > I don't use demon, so I've no idea if they permit you to have an MX in 
> > the chain.  Basically though, if your home server is on a static IP, you 
> > set it up to handle mail for vanitydomain.demon.co.uk, and set up the 
> > individual virtual users, and perhaps initially, a catch-all (until you 
> > clean things up), then request demon to make DNS changes to set your home 
> > server up as the primary MX for that host, and their mail server to be 
> > the backup MX.  When a message comes along for you, it'll try to deliver 
> > to your home machine first, and if it's not accessible for some reason, 
> > it'll go to the backup MX at demon, and periodically, they'll try to send 
> > it along to the primary (your home server).
> 
> As far as I can tell I don't think I can do this. I have not yet given up
> looking into it, but I am thinking about moving away from Demon anyway. I
> signed up with Demon sometime in the 1980's - they were my dial-up provider
> and allowed my first forays into the Interweb. I was seduced by the "infinite
> number of email addresses" when other ISPs were only offering 5 email
> addresses. I keep the account mainly because business contacts - some from
> years ago - still pop up as this will be the only address they have for me. As
> time goes on this happens less and less and I feel more confident about
> closing it down. As I no longer need the account to access the Internet I am
> paying £10 a month for email...
> 

When we used Demon for our company several years ago, we had an MX
record set up that pointed to our company email server, with a back-up
pointing to the parent company's US one instead. Unless they've
downgraded their services, I'd expect them to continue to offer it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
mehma sarja | 6 Jun 2009 10:01
Picon

Newbie Question - Whitelist Howto?

Sorry for such a popular request - I have no access to the old messages on this list. The link is broken. Trying to get a whitelist going. I don't understand why there is no match. I am sending in a message from a gmail account - which is in the whiltelist file. Instead of putting it in the testing mailbox, it is delivered to the inbox.


#### Whitelist Recipe
FORMAIL = "/usr/bin/formail"
file = $HOME/.whitelist
searchFields = "-xSender: -xFrom -xFrom: -xReturn-Path: -xReply-To:"
EGREP = "/bin/egrep"

:0
*$ $FORMAIL  $searchFields | $EGREP --quiet --ignore-case --file='$file'
.testing/

===========
RESULTS
procmail: No match on "/usr/bin/formail  -xSender: -xFrom -xFrom: -xReturn-Path: -xReply-To: | /bin/egrep --quiet --ignore-case --file='/user/jgold/.whitelist'"

===========
.WHITELIST consists of
jgold <at> gmail.com
jgold <at> fun.com

===========
DATA
procmail v3.22 2001/09/10
formail v3.22 2001/09/10
egrep (GNU grep) 2.5.1
Linux jgold.usc.edu 2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:39:21 EDT 2009 i686 i686 i386 GNU/Linux

Thanks in advance,

Mehma

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
Permalink | Reply | 501 comments |
headers
LuKreme | 7 Jun 2009 01:31
Favicon

Re: Newbie Question - Whitelist Howto?

On 6-Jun-2009, at 02:01, mehma sarja wrote:
> Trying to get a whitelist going.

(I think Sean wrote this whitelist originally, I mucked it up)
:0 h
CLEANFROM=|formail -IReply-To: -rtzxTo:

WHITELIST=$HOME/.friends

# we require a trailing space or tab after the address match, whether an
# mbox is specified or not.
ISLISTED=`grep -i "^$CLEANFROM " $WHITELIST`

# This recipe will set VARIABLEFOLDERNAME ONLY if there is a mailbox
# defined in the whitelist data file.  You can set a default above  
here, or
# check for a blank VARIABLEFOLDERNAME elsewhere.
:0
* ISLISTED ?? ^[^ ]+[   ]+\/[^  ]+
.$MATCH/

:0E
* ! ISLISTED ?? ^^^^
.Whitelist

$ cat .friends:
Fred <at> example.com Friends.Fred
Alice <at> example.com Friends.Alice
George <at> example.com Friends.George
Sally <at> example.com Friends
Mike <at> example.com Friends
Brad <at> example.com
Mitch <at> example.com Family.Mitch
Oscar <at> example.com Family
Meg <at> example.com Family.Mom
Ziggy <at> example.com Family.Dad
Debbie <at> example.com

(the lines without a mailbox name have a trailing space, as specified  
in the comments above)

--

-- 
Support bacteria - they're the only culture some people have.
Permalink | Reply | 502 comments |
headers
Professional Software Engineering | 7 Jun 2009 04:22

Re: Newbie Question - Whitelist Howto?

At 17:31 2009-06-06 -0600, LuKreme wrote:

># we require a trailing space or tab after the address match, whether an
># mbox is specified or not.
>ISLISTED=`grep -i "^$CLEANFROM " $WHITELIST`

Seems that using:

CLEANFRMRE=$\CLEANFROM
ISLISTED=`egrep -i "^$CLEANFRMRE([      ]|$)" $WHITELIST

Would obliviate the need to have trailing whitespace - either there's a 
separating space or tab, or there's an EOL.  I would think that doing this 
would be preferrable since tracking down that one address that doesn't have 
a trailing whitespace can be a bugger when you don't _see_ the whitespace 
in the typical editor.

There's two other significant changes here as well: I'm using the "escape 
the regexp elements in the variable" syntax - so DOTS in the address are 
escaped, rather than interpreted as regexp wildcards, though since that is 
a procmail syntax, not a shell, I assign the escapement to another variable 
to use within the shell operation, and I also anchor the address to the 
start of the line (ensuring that we don't match "smith <at> example.com" to 
"fred.smith <at> example.com" in the file).

---
  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.
Permalink | Reply | 1 comment |
headers
mehma sarja | 7 Jun 2009 09:15
Picon

Re: Newbie Question - Whitelist Howto?

Thankyou LuKreme and Sean,

I have tried LuKreme's recipe and it works! Don't mind the space but I'll try Sean's suggestion as well.

Thanks for sharing, I really do appreciate it.

Mehma
===

On Sat, Jun 6, 2009 at 7:22 PM, Professional Software Engineering <PSE-L <at> mail.professional.org> wrote:
At 17:31 2009-06-06 -0600, LuKreme wrote:

# we require a trailing space or tab after the address match, whether an
# mbox is specified or not.
ISLISTED=`grep -i "^$CLEANFROM " $WHITELIST`

Seems that using:

CLEANFRMRE=$\CLEANFROM
ISLISTED=`egrep -i "^$CLEANFRMRE([      ]|$)" $WHITELIST

Would obliviate the need to have trailing whitespace - either there's a separating space or tab, or there's an EOL.  I would think that doing this would be preferrable since tracking down that one address that doesn't have a trailing whitespace can be a bugger when you don't _see_ the whitespace in the typical editor.

There's two other significant changes here as well: I'm using the "escape the regexp elements in the variable" syntax - so DOTS in the address are escaped, rather than interpreted as regexp wildcards, though since that is a procmail syntax, not a shell, I assign the escapement to another variable to use within the shell operation, and I also anchor the address to the start of the line (ensuring that we don't match "smith <at> example.com" to "fred.smith <at> example.com" in the file).

---
 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.


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

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
Permalink | Reply | 0 comments |
headers
Rick Romero | 9 Jun 2009 05:45
Favicon

Procmail, FreeBSD 7.2 NFS (w/ZFS?) Maildir issue

Hey guys,

I run Qmail/vpopmail based mail server(s) on FreeBSD, and due to recent
ZFS issues with 7.x on the mailbox stoage server, I've upgraded to
kernel 7.2-stable.  This seems to have upgraded NFS to v4 as well.
I've tried using NFS from ZFS's own export, plus 'external' NFS
via /etc/exports.  Both behave the same.

Due to that upgrade, I seem to have come across a bug in procmail's
Maildir delivery.  This doesn't occur with maildrop or vdelivermail, and
I also found a post from December regarding NFSv4 in general:
http://drewp.quickwitretort.com/2008/12/24/1

In any case, when processing through procmail from either FreeBSD 6.2 or
a FreeBSD 7.2 NFS client, the following occurs in my procmail.log:
procmail: Match on "^X-Spam-Status:.*Yes"
procmail: Error while writing to
"/usr/home/vpopmail/domains/havokmon.com/rick/Maildir/.Spam/tmp/1244517910.82369_0.www51.havokmon.com"
procmail: Couldn't create or rename temp file
"/usr/home/vpopmail/domains/havokmon.com/rick/Maildir/.Spam/tmp/1244517910.82369_0.www51.havokmon.com"

The file is then 'left' in /tmp :

# ls
-la /usr/home/vpopmail/domains/havokmon.com/rick/Maildir/.Spam/tmp/1244517910.82369_0.www51.havokmon.com

----------  1 vpopmail  vchkpw  0 Jun  8
22:25 /usr/home/vpopmail/domains/havokmon.com/rick/Maildir/.Spam/tmp/1244517910.82369_0.www51.havokmon.com

The file gets created with no permissions.  From what the above post
says, it seems procmail uses O_EXCL in some way -which doesn't work
correctly over NFSv4.  I've also had the same issue with older FreeBSD
installs when editing a file with Vi - it creates a .swp file
incorrectly then complains.  Newer versions of Vi don't have that
problem.  Unfortunately procmail is up to date, and still has the same
problem.

Is this a known issue? Is there a fix?  My filters aren't all that
complicated (well, the individual scripts aren't :), I'd just like them
to work again.

Any sugestions are appreciated!  Thanks!

Rick
Permalink | Reply | 1 comment |
headers
Rick Romero | 11 Jun 2009 22:24
Favicon

Re: Procmail, FreeBSD 7.2 NFS (w/ZFS?) Maildir issue

This seems to be a known issue with NFS and ZFS on FreeBSD 7.2-STABLE.
http://www.freebsd.org/cgi/query-pr.cgi?pr=135412

Quoting "Rick Romero" <rick <at> havokmon.com>:

> Hey guys,
>
> I run Qmail/vpopmail based mail server(s) on FreeBSD, and due to recent
> ZFS issues with 7.x on the mailbox stoage server, I've upgraded to
> kernel 7.2-stable.  This seems to have upgraded NFS to v4 as well.
> I've tried using NFS from ZFS's own export, plus 'external' NFS
> via /etc/exports.  Both behave the same.
>
> Due to that upgrade, I seem to have come across a bug in procmail's
> Maildir delivery.  This doesn't occur with maildrop or vdelivermail, and
> I also found a post from December regarding NFSv4 in general:
> http://drewp.quickwitretort.com/2008/12/24/1
>
> In any case, when processing through procmail from either FreeBSD 6.2 or
> a FreeBSD 7.2 NFS client, the following occurs in my procmail.log:
> procmail: Match on "^X-Spam-Status:.*Yes"
> procmail: Error while writing to
> "/usr/home/vpopmail/domains/havokmon.com/rick/Maildir/.Spam/tmp/1244517910.82369_0.www51.havokmon.com"
> procmail: Couldn't create or rename temp file
> "/usr/home/vpopmail/domains/havokmon.com/rick/Maildir/.Spam/tmp/1244517910.82369_0.www51.havokmon.com"
>
> The file is then 'left' in /tmp :
>
> # ls
> -la  
> /usr/home/vpopmail/domains/havokmon.com/rick/Maildir/.Spam/tmp/1244517910.82369_0.www51.havokmon.com
>
> ----------  1 vpopmail  vchkpw  0 Jun  8
> 22:25  
> /usr/home/vpopmail/domains/havokmon.com/rick/Maildir/.Spam/tmp/1244517910.82369_0.www51.havokmon.com
>
> The file gets created with no permissions.  From what the above post
> says, it seems procmail uses O_EXCL in some way -which doesn't work
> correctly over NFSv4.  I've also had the same issue with older FreeBSD
> installs when editing a file with Vi - it creates a .swp file
> incorrectly then complains.  Newer versions of Vi don't have that
> problem.  Unfortunately procmail is up to date, and still has the same
> problem.
>
> Is this a known issue? Is there a fix?  My filters aren't all that
> complicated (well, the individual scripts aren't :), I'd just like them
> to work again.
>
> Any sugestions are appreciated!  Thanks!
>
> Rick
>
> ____________________________________________________________
> procmail mailing list   Procmail homepage: http://www.procmail.org/
> procmail <at> lists.RWTH-Aachen.DE
> http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
>
Permalink | Reply | 0 comments |
headers
LuKreme | 13 Jun 2009 03:31
Favicon

Escaping "^From "

This is the recipe that write out all my list mail:

:0
* ! LISTNAME ?? ^^^^
{
    :0
    .$LISTNAME.$MYDATE/

}

or

:0
* ! ^TO_kremels <at> kreme.com
{
    :0
    .Misc.not-to-me/
}

And yet, I am seeing mail that has lines beginning with "From " being  
escaped.

$ mail kremels
Subject: From test

This is a test of lines beginning with
 From and if they are modified by my procmail

 From here on, this is a test.

-- 
Signature
EOT
$ cat Maildir/.Misc.not-to-me/new/1244856111.5496_0.mail.covisp.net\: 
2\,S
Return-Path: <root <at> covisp.net>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on  
mail.covisp.net
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=3.5 tests=AWL,BAYES_50,NO_RELAYS
	autolearn=no version=3.2.5
X-Spam-Report:
	* -0.0 NO_RELAYS Informational: message was not relayed via SMTP
	*  0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
	*      [score: 0.4998]
	*  1.1 AWL AWL: From: address is in the auto white-list
X-Original-To: kremels
Delivered-To: kremels <at> covisp.net
Received: by mail.covisp.net (Postfix, from userid 0)
	id 43661118B595; Fri, 12 Jun 2009 19:21:49 -0600 (MDT)
To: kremels <at> covisp.net
Subject: From test
Message-Id: <20090613012149.43661118B595 <at> mail.covisp.net>
Date: Fri, 12 Jun 2009 19:21:49 -0600 (MDT)
From: root <at> covisp.net (Charlie Root)

This is a test of lines beginning with
 >From and if they are modified by my procmail

 >From here on, this is a test.

-- 
Signature

in procmailrc I have the following:

:0c
{
         :0
         /backup/imap.backup/
}

and that message gets written as:

$ cat /backup/imap.backup/new/1244856109.5499_0.mail.covisp.net
Return-Path: <root <at> covisp.net>
X-Original-To: kremels
Delivered-To: kremels <at> covisp.net
Received: by mail.covisp.net (Postfix, from userid 0)
	id 43661118B595; Fri, 12 Jun 2009 19:21:49 -0600 (MDT)
To: kremels <at> covisp.net
Subject: From test
Message-Id: <20090613012149.43661118B595 <at> mail.covisp.net>
Date: Fri, 12 Jun 2009 19:21:49 -0600 (MDT)
From: root <at> covisp.net (Charlie Root)

This is a test of lines beginning with
 From and if they are modified by my procmail

 From here on, this is a test.

-- 
Signature

so, somewhere between the initial backup write and the final write,  
the "^From " lines are getting escaped. Could this be SpamAssassin?

--

-- 
The person on the other side was a young woman. Very obviously a
	young woman. There was no possible way that she could have been
	mistaken for a young man in any language, especially Braille.
Permalink | Reply | 4 comments |

Gmane