[Fedora-infrastructure-list] fp.org Mail Server Bounce Issue

[Warren Togami]

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 at bar.mydomain.com. 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 at redhat.com