[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: postfix delivery options



* Ben Hartshorne (ben@hartshorne.net) [011010 14:48]:
> I'm not sure how to configure postfix to have the following behavior:
> *when I send mail to someone@hartshorne.net, it gets sent to
> hartshorne.net to be delivered to someone.
> *when I send mail to someone@green.hartshorne.net, it gets sent to
> hartshorne.net, and qmail interprets the address correctly, and delivers
> it.
> *when fetchmail injects any message, it gets thrown through procmail and
> delivered appropriately.
> *when an automated program generates mail to root, it gets delivered to
> EITHER root@green.hartshorne.net (which will get to me eventually) or
> just straight locally.  I don't really care.

FWIW, here's how I've done a similar thing in exim:

qualify_domain = gobo.doorstop.net
qualify_recipient = gobo

so if a user on gobo sends mail to an unqualified recipient, it gets
delivered locally to "recipient@gobo", which will never get routed
elsewhere. Also, any unqualified non-recipient ("from") address will be
qualified with gobo.doorstop.net, which is a virtual domain set up the
same way as your green.hartshorne.net (To any third-parties reading this
on the list: yes, I insist that it's the same setup. Indeed it is the
same machine!) To top it all off, I have trusted_users = mail:vineet so
that I can use customized envelope from addresses (which I set to
virtual domain address for mailing lists and the like).

Having never used postfix, I can't suggest how exactly to effect this,
only point out that exim can do it, so postfix must have a way also, and
I wouldn't be surprised if it looked similar.

> Now, the third point above may bely a misunderstanding on my part.  I am
> under the impression that fetchmail injects a message into the local
> mail delivery program, which then sends it through the .forward file
> into procmail, which actually writes the messages to different files.
> Is this correct?  
> Also, I believe that mutt passes of messages to the local delivery agent
> (postfix) to be dealt with and sent at it's leasure.  Is this correct?
> If both of those are right, is it true that both incoming and outgoing
> mail go through postfix at some point?  I think that's where my problem
> lies.

This is true, usually. Fetchmail likes to deliver to an SMTP daemon
running on localhost, but it can be persuaded to just hand mail straight
off to procmail.  fetchmail(1) has this to say about bypassing an SMTP
daemon and going straight to an mda:

When  forwarding  to  an  MDA, however, there is more possibility of
error.  Some MDAs are `safe' and reliably return a nonzero status on any
delivery error, even one due to  temporary  resource  limits.  The
well-known procmail(1)  program  is  like this; so are most programs
designed as mail transport agents, such as sendmail(1), and exim(1).
These programs give back a reliable positive  acknowledge­ ment  and can
be used with the mda option with no risk of mail loss.  Unsafe MDAs,
though, may return 0 even on delivery failure.  If this happens, you
will lose mail.  (endquote)

So it sounds like this would be safe. Also, more efficient, as you
wouldn't have to run an smtp daemon at all. You can effect this by
calling fetchmail with a -m argument or specifying the mda keyword in
your fetchmailrc.

Personally, I've switched from fetchmail to getmail. I can't give it a
wholehearted recommendation, though: I have it delivering straight to
procmail but since (as pointed out from fetchmail(1)) procmail is a
"safe" or "careful" mda, it occasionally farts out with a -1 return
value, meaning I have to run getmail a few times to grab all hundreds of
messages that trickle in from these mailing lists =) Fortunately, as
getmail is in python, it was easy to modify its default behavior of
giving the POP3 server a (doh!) RSET on such errors. That was a real
horror when I had a few hundred messages to download. One procmail stall
and it would RSET the server and try to start at the beginning next
time. (Maybe I should have filed a bug report with a patch...) Now at
least it just picks up where it left off, and a procmail rule keeps me
from getting duplicates when that happens.

I should warn that I would guess that fetchmail would behave the same
way when delivering straight to procmail, so watch out. (Do let me know
if it handles the problem better, though!)

good times,

-- 
Vineet                                   http://www.anti-dmca.org
Unauthorized use of this .sig may constitute violation of US law.
echo Qba\'g gernq ba zr\!             |tr 'a-zA-Z' 'n-za-mN-ZA-M'

Attachment: pgpICJnIk0Si0.pgp
Description: PGP signature


Reply to: