Problem
=======
Currently all incoming mail goes through redhat.com and is relayed to
the internal fp.o server on bastion, which handles alias forwarding.
This became more than an annoyance when a distributed bot-net began
flooding mail to random addresses at fedoraproject.org. Since redhat
accepted original delivery and fp.o was correctly rejecting it,
postmaster redhat was receiving the thousands of bounces.
Short-Term Solution
===================
All valid addresses at fp.o are now auto-generated into a whitelist
contained in /etc/mail/access.db from the auto-generated /etc/aliases
file. This could be further cleaned up to generate access.db
simultaneously as aliases, however it might not be worth doing because
this is a poor long-term solution.
All other mail destined for fedoraproject.org with unknown users will be
discarded without bounces. Additionally, this was added to the
sendmail.mc. (not yet checked into CVS)
diff -urN /tmp/sendmail.mc sendmail.mc
--- /tmp/sendmail.mc 2006-09-04 21:15:55.000000000 -0700
+++ sendmail.mc 2006-09-04 21:02:33.000000000 -0700
@@ -49,6 +49,7 @@
FEATURE(`use_cw_file')dnl
FEATURE(`use_ct_file')dnl
FEATURE(`access_db')dnl
+FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl # mail hub for fedora.redhat.com setup
"blacklist_recipients Turns on the ability to block incoming mail for
certain recipient usernames, hostnames, or addresses. For example, you
can block incoming mail to user nobody, host foo.mydomain.com, or
guest@xxxxxxxxxxxxxxxxx These specifications are put in the access db as
described in the Anti-Spam Configuration Control section later in this
document."
Please keep an eye out for failures in fedoraproject.org alias mail
delivery. We will be using this automatically generated access.db
whitelist until we deploy the ideal long-term fp.o mail solution.
Long-Term Solution
==================
Both Red Hat IS and Fedora Infrastructure team want fedoraproject.org to
directly handle its own mail. This will give us greater flexibility in
mail service maintainability as well as spam filtering. This would save
everyone time by dramatically reduce the amount of spam going through
our system. OTRS queue maintainers would also be less burdened due to
less spam crap.
While redhat cannot do full greylisting due to business concerns, I
personally want to be totally BOFH with greylisting. =)
(Infrastructure team would need to vote on this one as it is indeed
controversial.)
Due to the security considerations of running more than a dumb
forwarder, we will need to isolate the mail service from bastion. This
would mean a small network topology change, and maybe additional
hardware. I will be working on this in the coming weeks.
Thanks to Matthew Galgoci for his help in fixing this.
Warren Togami
wtogami@xxxxxxxxxx
