I must say that I have been somewhat quiet in my journal over the last month - This is because, as some in the Perl community know, I have started a new position. The position is as technical manager with a company called Bluebottle - The main focus of this company is the development of an enterprise level challenge-response type mail verification system. I started this full-time position just over two weeks ago, prior to which I was finishing up my commitments to my previous employer, and performing some preliminary code review and roll-out management for Bluebottle.
One particularly good thing about this position is that my employer has embraced the concept of open-source for this development and indeed is intending upon releasing much of what we develop back into the open source community.
This is going to be fun ...
I've been outspoken on my concerns about challenge-response systems. Do you have a way to address spoofing? I don't want to receive any more challenges because a spammer or a virus used my address in the From header. Can your product deal with this?
Re:Challenge Response
rob_au on 2003-07-12T23:43:49
This is a very important point that you raise - Currently there is minimal protection against spoofing within the system. The protection that does exist within the system relates to the single issue of a verification request to an unknown user upon the receipt of unverified mail. If subsequent mail is received from that sameFromaddress during the lifetime of the original verification request (currently set at seven days), no further verification requests are sent. Furthermore, the verification request that is sent to theFromaddress does not incorporate the full-body of the message, preventing the employ of "bounce-spamming" that we can see starting to be employed.It is my understanding however, that address spoofing is a widespread problem beyond the bounds of challenge-response systems alone - This of course does not negate the problem and indeed, that aspect of the system which I have described above does not come close to solving the problem in it's entirely, but does widen the spectrum from whence solutions can be drawn. If you do have any further ideas or references about how such address spoofing can be efficiently managed, I am more than happy to discuss them with you. Indeed, it is for just this type of feedback and critical review that I believe Bluebottle is so willing to embrace and support the open-source community.
Re:Challenge Response
chromatic on 2003-07-13T01:14:10
Good on you for not sending the full-body. That's a big plus.
Yes, spoofing is outside the scope of challenge response. I'm quite pleased with the ideas behind SPF, but that renders a lot of justifications for challenge response invalid, as far as I can see.
Re:Challenge Response
rob_au on 2003-07-13T08:36:38
Thanks for the reply chromatic.The big issue with SMTP+SPF which I see (albeit based upon my limited reading on SMTP+SPF to date) however is that SPF is not backwards-compatible and requires a high-level of adoption by proponents to be truly effective. I will however investigate this technical option further and have a thorough read through the SMTP+SPF documentation
