[PLUG] smtp with sender subscription...

Michael Robinson plug_0 at robinson-west.com
Tue Apr 13 00:25:02 UTC 2004


Rationale...


I want to reconfigure postfix 2.0.19 or set up qmail
as a frontend to it so that you have to subscribe to
my site to send me email.  Essentially, if an unknown
sender tries to email my server, a bounce should be
generated explaining that they must subscribe to send
me email.  This way, random spammers fearing
identification probably won't bother to respond and
I'll actually be able to spare my users from a lot of
upsetting unsolicited garbage that is very hard to detect
with 100% accuracy.  


The Problems...


For a sender must subscribe system to work well,
local users need to be able to manually modify
subscription lists for mailing lists and trusted private
addresses, preemptively.  For example, I would put
plug at lists.pdxlinux.org in a subscribed list for
any account I want to use it from.
  
Forcing sender subscription may be shunned
by some, but I'm fighting a losing battle trying to add
iptables rules in order to block the addresses of
abusers.  Not knowing how long an address should be
blocked and realizing as time goes on that the sheer
length of the list is becoming a problem for manual
maintenance methods, it's try another approach or
eventually shut down.  I already use spamassassin
and Mailfilter, but I'm not stopping annoying ads.  

It amazes me that there is so much attempted traffic to
sonya.h on my mailsite, yet I don't host a sonya.h
account.  Abusive senders should have figured
that out by now.  I'm tired of blocking ips to try and
get rid of useless errors from computers trying to
send to sonya.h.  

I don't want a system where every one is
blacklisted except for a short whitelist, that doesn't
address growth very well.  

SMTP authentication is out, after all, all that
anyone has to do is copy the authentication
if you're running through a clear text smtp
server or relay.  Authentication doesn't
seem friendly to adding new senders.

...

On solving problem with a sender must subscribe
approach...


I should probably have a website that people have to
go to to subscribe to my site before they can email
me, though I'm open to suggestions.  

The hold feature in postfix-2.0.19, does it work
indefinitely?  I'm wondering thinking to hold the
mail from unsubscribed senders until the sender
subscribes or a reasonable amount of time so
that I'm not holding onto junk forever.

Subscription should be a one time thing
for a sender for as long as the local
recipient(s) approve.
 
Maybe I should run qmail in parallel with postfix,
just for subscription purposes, feeding the messages
that are passing subscription check through into my  
existing Postfix/Mailfilter/Clamav/spamassassin
setup.  Maybe I'll have to alias a second private
address onto my mailserver to give qmail a home.

I've had trouble with valid senders saying helo with
unregistered addresses.  I either work out an override
feature when it comes to hostname checking, or I'll
have to give up on hostname checking entirely.  Why
isn't who you say hello as defined more rigidly?  
What are the implications for setting up a
senders must subscribe smtp server?


Summary...


Exposed to the whole Internet and attempting to
stop abusers of my mail site, I'll never succeed
with a block individual ips approach. 
Spamassassin and Mailfilter help, but they're
not stopping drug ads.  I can hold a message
perhaps until it's sender subscribes, so losing
messages should be mitigateable.  The goal is
to stop spam or at least know where it's coming
from.

I'd be imposing opt-in on senders with a subscription
requirement, a lot of computer generated stuff should
be stopped cold by this.  Especially if I make the
subscription process something that can only be done
by a human, albeit over the Net for convenience, a
subscription requirement should affectively cut down
UCE/spam.  A web site could have an agreement as
part of subscription that legally protects me and my
local users.

Yes  or no on force sender subscription?

     --  Michael C. Robinson





More information about the PLUG mailing list