On 19-nov-2006, at 13:28, Paul J Stevens wrote:
Tom Allison wrote:
Well, I'm back online after tossing dovecot for dbmail. The
transition
was much easier than I expected except that I had one stupid
setting and
lost a ton of email. I'm still alive so I probably won't miss it
that
much -- there's a tarball somewhere.
After sorting through a lot of notes there are a number of things
that I
can't seem to get figured out just yet.
I'm using postfix + dbmail + postgresql with hopes (tomorrow) of
setting
up dspam and clam-av. I have clam-av running now but it's an old
version and might not work. I also was using bogofilter but not
anymore.
postfix:
local_recipient_maps
I added a pgsql-recipients file with a pointer to the
dbmail_aliases table
to do the recipient lookups. This doesn't work very well.
I changed my email address and mapped an alias in dbmail so now
anything
that is delivered to my real name isn't seen as an alias. Only email
that is delivered to an alias is seen.
And I managed to duplicate the aliases table (/etc/aliases.db)
with the
dbmail_alias table and that got things badly fuggered.
Right now I'm running no local_recipient_maps. All my aliases are
done
in /etc/alias. I missed a beat on this configuration or am I
expected
to add myself as an alias to myself? Seems strange to me.
actually running with an empty local_recipient_maps makes a lot of
sense, if you use lmtp delivery. Postfix will pass along everything to
dbmail-lmtpd which will do the address resolving; making postfix do
hard
bounces (550 reject) is an address is not tied to a local recipient.
No it won't :-)
First of all, bounce and reject are not the same thing. Bouncing occurs
after "250 OK" on the receiving side and the mail has thus been
accepted,
which should be avoided at all cost, whereas rejecting means the mail is
not accepted at the receiving side and it is left up to the
connecting smtp
client on the sending side to further process (bounce, defer) the
message,
depending on the type of reject code (4xx, 5xx). This occurs before
"250 OK"
on the receiving side. I'm sure you all know this already :-)
This is why you should also propagate recipient maps to your backup MX
servers.
The lmtp client is invoked by the Postfix qmgr, so the actual
delivery takes
place _after_ queueing. Unless there exists some magic
external-smtp-to-internal-lmtp pipethrough shortcut feature in
Postfix that I
am not aware of, this kind of setup _will_ generate backscatter (see
http://www.postfix.org/BACKSCATTER_README.html), which is "not done"
these days.
This means you should/must make a recipient map available to the Postfix
smtpd. With DBmail, the most logical option is to use an SQL
recipient map,
unless you suffer from a lot of dictionary attacks, which could
seriously
affect the performance of your database server.
Tom should explain in more detail what is going wrong with his alias
lookups.
One common pitfall while doing SQL recipient validation is to forget
that
your Postfix smtpd is chrooted, in which case you should use the
proxymap
server to facilitate connections to your database, e.g.:
local_recipient_maps = proxy:pgsql:/etc/postfix/recipients_pgsql.cf
dbmail mailing list -- there's another email address out there
'tallison' that isn't going to be very useful anymore. If someone
could
make it go away I would appreciate it. But I can't seem to send
email
from that address just yet.
Please send mail to [EMAIL PROTECTED] The folks at IC&S control
the mailman installation.
Hmm, I can't find any reference to a "tallison"?
Leander
