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
the form whateverIwant(_at_)myvanitydomain(_dot_)demon(_dot_)co(_dot_)uk
(the ".demon.co.uk"
bit is real).
Right, so three accounts are just mailboxes at those respective ISPs,
where you have nothing to do with the domain, while the last one you
_might_ be able to have the MX record updated to point to your host, and
a secondary to the mailhost of that ISP.
Correct - although I don't think I can do anything about the Demon.net account
either. (Their web presence is www.demon.net but my account is
xxx(_at_)mychosenname(_dot_)demon(_dot_)co(_dot_)uk).
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...
If your home box isn't on a static IP, then you need to look to use a
dynamic DNS service, and set up a cron job to update your IP information
with that service (I don't use any of them myself, but this is how it
works more or less). Then, when you know the dynamic DNS stuff is
working, go do all the stuff you'd be doing for the MX change above, but
specifying your dynamic DNS hostname (you can use the dynamic dns service
domain for the hostname - no need to try to get it registering as a host
within your own domain, which really would just be a CNAME to the dynamic
DNS host if you had your own domain). If your host goes offline and back
online (say, if you were on dialup), you can use fetchmail to "tickle"
the backup MX to process its queue, rather than waiting for the backup MX
to "get around to it" -- ETRN is the SMTP command, and you should find
that in the fetchmail docs, if you need it.
This is interesting. I have registered an account with Dydns.com and I have
set up a daemon that updates it. I don't know if it really works as my IP
hasn't changed. I am still trying to get my head around all the MX stuff.
[snip...]
Anything returning unmolested from that lot then gets filtered for
wife/son and delivered to /var/spool/mail/username. This is the bit
which Sean feels should be done by sendmail (and I agree).
'cepting that you're fetchmailing, which wasn't originally disclosed. If
fetchmail is pulling these messages down from a single mailbox, via POP
for instance, you don't have envelope data - it's already been
"delivered" when your upline ISP received it and put it into the mailbox
you're now retrieving it from. Once that happened, the envelope data
went "kerpoof".
Ahh.. Beginning to get it now...
Then (still in /etc/procmailrc) I have another INCLUDERC that sorts my
mail into various mail folders that I have organised (I know that this
should be done by ~/.procmailrc but I can't get that to work - see
below).
Anything left drops through into /var/spool/mail/mark
This is because of $DEFAULT, or because you're expressly doing it in the
global rc?
i
Well yes. But I have tried it with a test message explicitly designed not to
hit any rules, and I do not have $DEFAULT set (or is this picked up from
somewhere else?).
Problem 1
=========
What triggers $HOME/.procmailrc ?
A message which isn't already delivered by the etc/procmailrc. If your
global rc delivers the message, procmail will stop processing, never
loading up your personal one. You might also have permissions issues on
the rc file that makes procmail decide not to open it - if so, it should
get logged.
I do have a /home/mark/.procmailrc but it does not seem to get used (I
have tried) and hence I do my personal mail folder organisation using an
INCLUDERC off of /etc/procmailrc.
Is this because the mail goes into /var/spool/mail/username?
Because the global rc is _delivering_ it there? Yea, that'd do it.
Yes, except where I have tested with that directive turned off (see above).
Problem 2
=========
How do I rope sendmail in to help me here (apologies for OT)?
Well, the message isn't arriving at your host via SMTP - fetchmail is POP
or IMAP'ing the message and invoking procmail with it - so your SMTP
config isn't being used.
[snip...]
Any tests I can try to see if sendmail is actually registering the
virtusertable entry?
sendmail -bv address
# sendmail -bv mark
mark... deliverable: mailer local, user mark
# sendmail -bv joebloggs(_at_)mydomian(_dot_)demon(_dot_)co(_dot_)uk
joebloggs(_at_)mydomain(_dot_)demon(_dot_)co(_dot_)uk(_dot_)(_dot_)(_dot_)
deliverable: mailer esmtp, host
mydomain.demon.co.uk, user joebloggs(_at_)mydomain(_dot_)demon(_dot_)co(_dot_)uk
sendmail -bv fredsmith(_at_)madeupname(_dot_)com
fredsmith(_at_)madeupname(_dot_)com(_dot_)(_dot_)(_dot_) deliverable: mailer
esmtp, host madeupname.com.,
user fredsmith(_at_)madeupname(_dot_)com
Now should the address joebloggs@ etc. not show as being deliverable to user
"son" as it is set in virtusertable?
Anyhow...
Summary
=======
I thank you for taking the time to help me. You have given me a great deal to
think about. In essence, I think that for the time being at least I will stick
with my (working) setup. Clearly, unless I can take fetchmail out of the
delivery equation I cannot start using sendmail for processing. This is not a
trivial exercise (for me at least).
The sad reality is that this looks more difficult than I first thought, and
unfortunately I don't have the time at present to devote to it. Definitely a
project for the future though...
I would however still like to learn more. I have looked at several howtos on the
web, but they are mostly geared towards installing and configuring the various
bits of software. Nowhere have I found a simple overview explaining the
concepts of a mail server (for a beginner). If anyone can suggest such a
primer I would be very grateful.
Thank you once again for all your time and help, it is much appreciated.
Best regards
Mark
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail