Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of rob_au (1845)

Saturday July 12, 2003
07:35 AM

New position

[ #13408 ]
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 ...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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?

    • 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 same From address during the lifetime of the original verification request (currently set at seven days), no further verification requests are sent. Furthermore, the verification request
      • 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 [pobox.com], but that renders a lot of justifications for challenge response invalid, as far as I can see.

        • 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