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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
