Re: Anti-Spam Idea

> I had an idea I think could significantly reduce spam everywhere and
> thought I'd run it by this group to see how many reasons people might
> come up with why it might not work. It probably would require an
> extension of SMTP, but it should be a fairly simple one. It could be
> deployed gradually with no impact on existing systems. Its effectiveness
> would grow along with the rate of deployment. The main benefit is to
> filter messages from senders who spoof the sender address. In a nutshell
> here it is:
>
> When an originating server receives a request to send a message from one
> of its known clients, it would calculate a cryptographic hash (i.e. MD5
> or some such) over the message body, including any attachments, and save
> it in a table along with a time stamp. The hash would not have to remain
> long in the table once the message has been sent, so storage
> requirements should be minimal. It then processes and sends the message
> as usual. When the recipient server receives a message it calculates the
> same hash value in the same way. It then makes a request to the
> ostensible sending server, i.e. the one indicated in the header as
> originally intended by SMTP, asking to validate the hash. The hash is
> included in the request. If the originating server does not yet
> implement the verification extension it will respond with an error
> indicating that it does not recognize the request. If the originating
> server does implement the verification extension it will check its hash
> table for a match with the hash from the requestor, and return a
> response indicating whether a match was found. The recipient server then
> makes a disposition in one of three cases:
>
> 1) The apparent sender does not implement the new protocol; keep the
> message.
> 2) The actual sender had the requested hash in its table; keep the message.
> 3) The apparent sender did not have the requested hash in its table;
> discard the message.
>
> If the message was retained after this check the server would then apply
> any other spam filters and black-list checks as it otherwise would.
> After a configurable time each message hash would be flushed from the
> sender's table. As more servers update to the protocol extension it
> would become increasingly difficult to spoof a return address.
> Eventually most messages with false return addresses would get discarded
> by the recipient server, and the recipient client would never see them.
>
> So that's it. Ok. I'm ready to catch the spears now.

Are you trying to stop spam that has its headers modified with extra server
passing messages or stop spam that just alters the From: address?

The first would work with this as you would read the headers to find out which
server originated the message and request the hash from it not sure how the
latter would since most ISPs allow a user to send with any address in the From:
as long as they are either on the ISPs network, or have authenticated against
the server. Stopping the spoofing of the From: is not something I would really
want to see per se as I use my ISPs mail server for all outbound messages, but
don't necessarily use an address that is on that same network (same thing with
Cox users).

If this was implemented to block spoofed From: lines, it would probably block a
lot of legitimate mail. Examples would be indivuals who have a personal address
with their ISP, but also a work address or other alternative address that they
might use to reach certain people...
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss