SPAM handling.

[Paul Hammant <Pa...@yahoo.com>]

I've quickly looked at the latest source, but can't see it ...... does 
JAMES have a configurable mechanism for checking domain names of 
senders.  Not perfect, but a form of SPAM defence.  If the domain names 
were fake, then JAMES could simply delete the email as it comes in, and 
never forward to the account holder.

A related idea -> SMTP and it's relaying nature is decades old and part 
of the problem.  If a new standard emerged whereby incoming email was 
checked back with the alleged sending server and similarly binned if not 
actually send my that server, then SPAM could again be diminished.  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.  This could be an optional extension to the sprawling mass of mail 
standards.  Granted not all servers would conform to the standard at the 
outset, but in time more and more would include the appropriate headers. 
 An early adopter (like myself) could configure their account to (at a 
particular moment in time of their choosing) no longer accept such 
un-authenticated email.  This the world of email could undergo a gradual 
transition from chaos to authenticated.

i.e - Did you send this?
 - Yes, it's fine.
 - No, it was faked elsewhere.
 - Yes, but it is not, in retrospect, authentic.
 - Yes, but it has possibly suspect contents (Virus etc.).
 - Yes, but the account is now disabled for some reason or other (e.g. 
breach of AUP).

I'm thinking that these are genuine API requests, rather than API calls 
packaged as formatted emails:
  To=Auto-Authenicator@yyyyyyy.com
  Body="Hi, I'm the email server JAMES running at xxxxx.com.  Did you 
send and email to me :...."

Perhaps I am thinking that some of you folks could take this idea (if 
not mulled over already) and push towards a IETF RFC.  Hell, go XML at 
the same time!

Regards,

- Paul H


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

Re: SPAM handling.

[Paul Hammant <Pa...@yahoo.com>]

Serge,

>There's a matcher that comes with JAMES called SenderInFakeDomain.  It's
>included but commented out of config.xml by default.  It looks at the
>address given in the MAIL FROM and matches if it is not a valid domain.
>Like you say, a form but not perfect piece of defense.
>
Cool.

>As for the verification system, it sounds interesting... I would think with
>some sort of notification between servers, a server could build up a list of
>valid email addresses that it would accept.  You could do it something like
>this....
>
>1. If a message arrives from a sender that's not on the approved list, it
>puts it in a holding queue.
>2. We send a message to that sender asking them to verify the address.  This
>could use VERP syntax so the user just replies.
>3. For smart (JAMES) servers that receive these address verification
>requests, it could spot these request validations, and send the validation
>response immediately (so the user doesn't see it and have to approve it).
>4. Once the address is validated, the message is pulled out of the holding
>queue.
>
No no, it checks every message every time.  It it keeps a list, it's a 
list of servers that soppirt the verification protocol (a spammer could 
masquerade as a user from a verify capable mail server, but leave off 
the verification headers).  And it verifies messages not senders, note 
the reply types in my orig email.

>I think this is rather aggressive, but I wonder as spam becomes more
>pervasive whether it'd be useful.  Also, in theory you could also see if a
>message is digitally signed, and if so, automatically approve the email
>address.
>
Signing is good too, but not widespread as getting and configuring 
certificates is felt to be too hard for most users to do.

>Interesting thoughts...shouldn't be too hard to put together in JAMES.
>
That's true, but what I am really saying here is that the is opportunity 
for a few of you guys to get together and post an RFC.

The basic issue is that the relaying nature of  email is the reason that 
Spammers choose to fake postings and "borrow" resources.  There is 
legislation in place to force spammers to give options to allow spamees 
to remove themselves from lists.  When it works it's pointless.  Have 
you every tried to remove yourself from a list.  It's so ineffectual. 
 No, it's the faking and sending via hacked mail servers that the main 
reason spam still exists.  If we move slowly towards verified email then 
we'll beat SPAM. If that means that SMTP2 comes into being, then fine by 
me - we dual support multiple transports.  Come on guys, seize the 
opportunity, pen a RFC and put yer names on it.

It works best as a standard heh?

- Paul


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

Re: SPAM handling.

[Serge Knystautas <se...@lokitech.com>]

There's a matcher that comes with JAMES called SenderInFakeDomain.  It's
included but commented out of config.xml by default.  It looks at the
address given in the MAIL FROM and matches if it is not a valid domain.
Like you say, a form but not perfect piece of defense.

As for the verification system, it sounds interesting... I would think with
some sort of notification between servers, a server could build up a list of
valid email addresses that it would accept.  You could do it something like
this....

1. If a message arrives from a sender that's not on the approved list, it
puts it in a holding queue.
2. We send a message to that sender asking them to verify the address.  This
could use VERP syntax so the user just replies.
3. For smart (JAMES) servers that receive these address verification
requests, it could spot these request validations, and send the validation
response immediately (so the user doesn't see it and have to approve it).
4. Once the address is validated, the message is pulled out of the holding
queue.

I think this is rather aggressive, but I wonder as spam becomes more
pervasive whether it'd be useful.  Also, in theory you could also see if a
message is digitally signed, and if so, automatically approve the email
address.

Interesting thoughts...shouldn't be too hard to put together in JAMES.

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: <ja...@jakarta.apache.org>
Sent: Wednesday, October 24, 2001 12:47 PM
Subject: SPAM handling.


> I've quickly looked at the latest source, but can't see it ...... does
> JAMES have a configurable mechanism for checking domain names of
> senders.  Not perfect, but a form of SPAM defence.  If the domain names
> were fake, then JAMES could simply delete the email as it comes in, and
> never forward to the account holder.
>
> A related idea -> SMTP and it's relaying nature is decades old and part
> of the problem.  If a new standard emerged whereby incoming email was
> checked back with the alleged sending server and similarly binned if not
> actually send my that server, then SPAM could again be diminished.  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.  This could be an optional extension to the sprawling mass of mail
> standards.  Granted not all servers would conform to the standard at the
> outset, but in time more and more would include the appropriate headers.
>  An early adopter (like myself) could configure their account to (at a
> particular moment in time of their choosing) no longer accept such
> un-authenticated email.  This the world of email could undergo a gradual
> transition from chaos to authenticated.
>
> i.e - Did you send this?
>  - Yes, it's fine.
>  - No, it was faked elsewhere.
>  - Yes, but it is not, in retrospect, authentic.
>  - Yes, but it has possibly suspect contents (Virus etc.).
>  - Yes, but the account is now disabled for some reason or other (e.g.
> breach of AUP).
>
> I'm thinking that these are genuine API requests, rather than API calls
> packaged as formatted emails:
>   To=Auto-Authenicator@yyyyyyy.com
>   Body="Hi, I'm the email server JAMES running at xxxxx.com.  Did you
> send and email to me :...."
>
> Perhaps I am thinking that some of you folks could take this idea (if
> not mulled over already) and push towards a IETF RFC.  Hell, go XML at
> the same time!
>
> Regards,
>
> - Paul H
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org