[TriLUG] Another seal broken... thinking of installing a C/R anti-spam system

Jon Carnes jonc at nc.rr.com
Sun Jan 28 18:27:07 EST 2007


Alright, lets try to suspend our love of the current standards and see
if we can think a bit out of the box...

Right now you can have just about anything in any mail field and it
transports just fine - and as long as everyone is honest and nice, that
works. The problem is that spammers are neither honest nor nice. And the
current system makes it hard to hold them accountable - or to properly
identify the folks who are allowing the abuse to propagate.

We are going to have to change the standards we use for mail transport.
Lets not call it "smtp-auth" since that is a different standard from
what I described (though similar)... and some folks can't seem to get
beyond the name... Lets call the new standard: TriLUG-SMTP. And lets see
if we can design (in TriLUG) a better way of moving mail around on the
internet - one that helps us better battle spam. 

This means that we will have to wrap our minds around some
modifications. I propose that as part of TriLUG-SMTP we make folks login
to a local domain sever in order to drop off mail From their account. 
If we modify the From: field to have the authenticated
username at domain_name.org then: Yes, we'll need to mod the way we handle
groups.

Your group mail will actually come from the listname, so this mail would
come "From: trilug at trilug.org". The "Reply-To:" could be your email
address.

If you drop off mail at a private domain that then resends it as
you at some-other-domain.org, then your private server will need to have
sending info (name/password) in order to authenticate as you and send it
out.  This is similar to the way that Fetchmail works when it POP's
public servers for a private local net.

Try to keep up with me here.

Now, you are right in that a spam-bot could then simply grab the
authentication of the local user and send the mail out as that
individual... but only that individual. That puts a real damper on the
spammers abilities, and increases our ability to battle the spam.
The domain ISP's will have a much better ability to battle the spam
originating on their nets.  

You are also right, that spammers will create whole domains just for
their spam - well we can already battle that.


On Sun, 2007-01-28 at 17:15, Brad Jorsch wrote:
> On Sun, Jan 28, 2007 at 12:40:58PM -0500, Jon Carnes wrote:
> > 
> > You're right, forwarding services would be more limited. However, your
> > "Reply-To:" should still work. Even though the "From:" would be whatever
> > local account you are using; the "Reply-To:" could still be the
> > forwarding service. 
> 
> Unless you're using SenderID, neither 'From:' nor 'Reply-To:' matters as
> far as SMTP goes. And even then, you probably want 'Sender:' rather than
> 'From:'.
> 
> For SMTP, we care about the 'Mail From', aka the Envelope Sender.
> 
> Requiring 'From:' to be the account being used for sending mail just
> doesn't seem workable. Right here, that would have to be
> sourceforge at anomie.xo, which is completely meaningless outside my LAN.
> Then the message would have to be *rewritten* with a different 'From:'
> when it gets passed on to my ISP's smarthost. Incoming mail would be
> even worse: Sourceforge would have to obliterate the actual 'From:' to
> forward it on to my ISP account, and every message I got would seem to
> be 'From' some-forwarder-process-user at sourceforge.net.
> 
> "Oh, but we'll make something for forwarders so they don't have to do
> that!" might be the response, but then every spammer would just pretend
> to be a forwarder.
> 
> 
> > Now that I'm looking around at Grey-listing, I'm seeing all kinds or
> > interesting stats (and kicking myself for not using it earlier). I'm
> > seeing stats of 90% of spam being turned away by just rejecting the
> > initial connection.... 
> 
> Interestingly enough, I've been looking at actually implementing
> greylisting the past few days. Probably only on hosts that do something
> wrong though, e.g. get listed on DNSBLs, have bad DNS on their HELOs,
> come from the wrong country, etc.
> 
> I'm not quite sure which parameters to pick, though. Initial delays run
> from effectively 0 to 1 hour or so, delivery windows are seldom
> mentioned, some recommend using the /24 instead of the /32 to allow
> delivery from big senders with lots of outgoing servers... Any advice,
> anyone?
> 
> 
> > The current system of SMTP has worked so well for so long, it is very
> > difficult to change it. But there is currently a problem with that
> > system. A growing problem. We need to address the problem of spam with
> > more than just defensive moves (like gray listing). 
> 
> Unfortunately, the only way to address spam is to make it unprofitable:
> income - cost <= 0. With huge zombie-nets to send the spam cost
> approaches zero, while there will always be stupid people to generate
> some income... Hopefully I'm just too pessimistic.




More information about the TriLUG mailing list