You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/02/28 11:17:53 UTC
Re: SPAM handling.
Chris,
> >Say the end-point recipient mail server made a digest of the message and
> >asked "did you send this" to the originating mail server, then it could
> >work.
>
> If you're going to do that, you may as well just have an SMTP command
> CALL-ME-BACK. You would get a connection from a server trying to
> deliver mail. It would ask CALL-ME-BACK?. If the receiver answered
> OK. It would disconnect. The receiver would then connect to the
> sender. There's an existing SMTP command to swap roles which it would
> do and then start receiving the email.
I have only just read this. It is a good idea. You folks should make
and RFC out of it and propose it to the IETF.
The feature could be phased in over time and mail administrators would
choose when they would turn off the not-CALL-ME-BACK capability. At
that moment all Spam and all email from servers that are not
CALL-ME-BACK capable are rejected. Harsh but fair, if phased in over a
couple of years.
The only way to beat Spam is to make the mail truly traceable to sender.
As long as they can fake headers and hijack servers, they will continue
to flout laws.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM handling.
Posted by Paul Hammant <Pa...@yahoo.com>.
Serge,
You are perhaps exposing that I am out of my depth here :-) My SMTP
knowledge is limited to poking it at college with Telnet.
I am trying to push the fact that some change of mail forwarding design
is needed to make the system more accountable and less spoofable. And
that five of you knowledgeble enough could sit down, publish an RFC and
gaim mindshare for the eventual migration from SMTP as is at the moment.
- Paul
>Paul,
>
>While I like the idea of XML headers, that seems to imply changing or
>dropping the MIME spec. Or were you referring to the handful of protocol
>commands (I don't really see that as headers)?
>
>Serge Knystautas
>Loki Technologies - Unstoppable Websites
>http://www.lokitech.com/
>----- Original Message -----
>From: "Paul Hammant" <Pa...@yahoo.com>
>To: "James Developers List" <ja...@jakarta.apache.org>
>Sent: Tuesday, March 05, 2002 4:34 AM
>Subject: Re: SPAM handling.
>
>
>>Danny,
>>
>>I appreciate there are blocks that can be put up using the current
>>protocols, but my contention is that blocks are the wrong solution. See
>>http://news.com.com/2100-1023-850761.html.
>>
>>What we need is some solution (that possibly changes the SMTP protocol)
>>that does not upset whole countries and closes the spoofing loopholes.
>> We will still be spammed, but the originators will be easier to find.
>>
>>I still think that we should migrate to a new, say, SMTP2 solution that
>>closes all the loopholes (upgrades to XML headers at the same time). At
>>some point in the future mail administrators choose to turn off support
>>to old SMTP and any mail servers trying to forward mail for them find
>>they just cannot connect. I.e. we are shooting the messanger in this
>>case (with bullet that takes two years to percolate through the system).
>>
>>My point is there smart enough brains in this list who can design
>>son-of-SMTP and propose it to the IETF.
>>
>>- Paul
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM handling.
Posted by Serge Knystautas <se...@lokitech.com>.
Paul,
While I like the idea of XML headers, that seems to imply changing or
dropping the MIME spec. Or were you referring to the handful of protocol
commands (I don't really see that as headers)?
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Tuesday, March 05, 2002 4:34 AM
Subject: Re: SPAM handling.
> Danny,
>
> I appreciate there are blocks that can be put up using the current
> protocols, but my contention is that blocks are the wrong solution. See
> http://news.com.com/2100-1023-850761.html.
>
> What we need is some solution (that possibly changes the SMTP protocol)
> that does not upset whole countries and closes the spoofing loopholes.
> We will still be spammed, but the originators will be easier to find.
>
> I still think that we should migrate to a new, say, SMTP2 solution that
> closes all the loopholes (upgrades to XML headers at the same time). At
> some point in the future mail administrators choose to turn off support
> to old SMTP and any mail servers trying to forward mail for them find
> they just cannot connect. I.e. we are shooting the messanger in this
> case (with bullet that takes two years to percolate through the system).
>
> My point is there smart enough brains in this list who can design
> son-of-SMTP and propose it to the IETF.
>
> - Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM handling.
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
I appreciate there are blocks that can be put up using the current
protocols, but my contention is that blocks are the wrong solution. See
http://news.com.com/2100-1023-850761.html.
What we need is some solution (that possibly changes the SMTP protocol)
that does not upset whole countries and closes the spoofing loopholes.
We will still be spammed, but the originators will be easier to find.
I still think that we should migrate to a new, say, SMTP2 solution that
closes all the loopholes (upgrades to XML headers at the same time). At
some point in the future mail administrators choose to turn off support
to old SMTP and any mail servers trying to forward mail for them find
they just cannot connect. I.e. we are shooting the messanger in this
case (with bullet that takes two years to percolate through the system).
My point is there smart enough brains in this list who can design
son-of-SMTP and propose it to the IETF.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SPAM handling.
Posted by Danny Angus <da...@thought.co.uk>.
just realise my response codes should be .. I was looking in the extensions
rfc :-)
421 4.7.1 originator/intermediate/host not yet authorised try later
554 5.7.1 originator/intermediate/host blacklisted contact
postmaster@wherever
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SPAM handling.
Posted by Danny Angus <da...@thought.co.uk>.
Actually,
we could put bad hosts into a blacklist and then send "571 host.domain has
been blacklisted contact postmaster@me.com" next time a blacklisted machine
connected (5xx is permanent error, i.e. "go away and stay away" BTW)
we could also parse message headers and test originating and intermediate
hosts ourselves too, returning 471 to the DATA command when they are
untested, and 571 when any of them are blacklisted.
And if we combined this with public blacklists it might be quite ferocious.
I think we need to test the reaction of other MTA's to various errors, after
all we need non ETRN MTA's to try again if they get 471.
I suspect we need to attach mailet processing to SMTP handling as well as
spool processing in order to use the mailet API in this role and to make
configuration consistent with the spool mailet processing.
I also think that we could extend the mailet API to allow this kind of
config to be supported..
<processor protocol="SMTP">
<handler command="MAIL" match="All" class="SMTPMAILHandler">
</handler>
</processor>
This would allow us to develop a clean set of overlapping command handlers,
more than one for each SMTP Verb, and matched against the contents of the
command where necessary.
Then we can do user checking, vhosts, and other stuff in an independant,
extensible and versatile way.
Something like this could validate users before mail is recieved (only
simpler I hope :)..
<handler command="RCPT" match="All" class="SMTPRCPTHandler">
<domain name="thought.co.uk">
<repository name="LocalUsers"
class="org.apache.james.userrepository.JamesUsersJdbcRepository"
destinationURL="db://maildb/thought">
<sqlFile>file://conf/sqlResources.xml</sqlFile>
</repository>
</domain>
<domain name="apache.org">
<repository name="list-james"
class="org.apache.james.userrepository.JamesUsersJdbcRepository"
destinationURL="db://maildb/apache">
<sqlFile>file://conf/sqlResources.xml</sqlFile>
</repository>
</domain>
</handler>
Obviously it would help clarify things if we could have..
1/ a seperate config for domains and their mail & user repositories
2/ a seperate config for each protocol
3/ fewer Global parameters (after all postmaster and servernames in a vhost
setting are relative to the host you are pretending to be)
Just some thoughts..
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SPAM handling.
Posted by Danny Angus <da...@thought.co.uk>.
Paul,
It doesn't get round open relays, anyone administering a mailserver should
know enough to prevent it from relaying, if they don't then there's a good
chance they won't know how to configure it to use CALL-ME-BACK.
I like the idea, but think it should go like this:
FYI here is a conversation I just logged
<quote>
220 mx3.dircon.net ESMTP Mirapoint 1.1.0; Fri, 1 Mar 2002 12:11:57 GMT
EHLO tarbolton.demon.co.uk
250-mx3.dircon.net Hello tarbolton.demon.co.uk [212.229.119.215], pleased to
meet you
250-8BITMIME
250-SIZE 31457280
250-DSN
250-ETRN
250-AUTH LOGIN
250-AUTH=LOGIN
250 HELP
ETRN thought.co.uk
250 Queuing for node thought.co.uk started
</quote>
this forces the server to send what it has queued for thought.co.uk but not
to us, it sends it to the correct host for that domain..
The old TURN command could be used to hijack other peoples mail, Coo what a
faux pas :-)
What we need to do is have a response to MAIL or HELO or EHLO that tells the
original to go away while we ponder its worth, we can then call it and use
ETRN
so looking at rfc 1893 we find these two paras:
<quote>
4.X.X Persistent Transient Failure
A persistent transient failure is one in which the message as
sent is valid, but some temporary event prevents the successful
sending of the message. Sending in the future may be successful.
X.7.1 Delivery not authorized, message refused
The sender is not authorized to send to the destination.
This can be the result of per-host or per-recipient
filtering. This memo does not discuss the merits of any
such filtering, but provides a mechanism to report such.
This is useful only as a permanent error.
</quote>
from which we cobble together this response:
471 host.domain is not authorised to deliver here we need to validate your
credentials, we will call back and use ETRN once we have succeded
which suggests that the sender should give up, but may try again
So ..
then we take the IP of the machine we've just been talking to, plus its HELO
name and check them using whatever tools we want (DNS, abuse lists, try an
SMTP connection, whatever you can think of,
our server would add this server to a list of approved hosts, which might
usefully have a TTL attached so we don't trust them forever.
and then we would call back using ETRN to make them send again what they
have for us, only this time their machine is in our little list
and they get through, or we ditch the ETRN altogether and wait until they
try again themselves.
How about that? it should succede where servers support ETRN, but also where
they dont, and whats more we can protect ourselves without relying on other
people.
Its not more than a partial answer tho.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>