[FQuest Announce] DomainKeys Signing of Locally Generated Email

[Bruce]

When: Thursday February 1st 2007
Window: 12:00AM to 1:00AM ET
Duration: 5 minutes
Who: All mail senders
What: DomainKeys signing of outgoing email

The mail system on all community servers will be enhanced to add the capability to add DomainKeys signatures to outgoing locally generated messages. This would be all messages generated by scripts, PHP, or other programs.

This is the second part of the previously announced (http://www.aota.net/forums/showthread.php?threadid=22489) DomainKeys implementation.

While the upgrade is in process, sending mail from scripts may temporarily break as permissions are adjusted. Outgoing email sent through SMTP and all incoming email will be unaffected.

--
Bruce
www.FutureQuest.net

[hobbes]

What about MQS?

[tappel]

I have an e-commerce shop that sends customers email notifications via PHP. Does this mean that "sign all" is now more appropriate for such email?

Tom

[DogAndPony]

I've get a number of sites that have contact forms and such that use SendMail...

So... "temporarily break" means... minutes? Hours? Until we report all bugs we find? Or will you be able to see and remedy all problems?

And/or do we have to add some sort of diagnostics and logging code to all scripts to let us know this has happened to particular messages?

I take it that if a message isn't sent, it's not just delayed, but lost, yes? Or no?

Thanks!

[Monty]

thank you to the FutureQuest team for this. Y'all rock.

[Stephen]

does this mean that scripts won't have to authenticate with the SMTP server to get a DomainKey signature? what exactly is the difference between the forthcoming and existing situation?

[sheila]

What about MQS?
CS upgrades and system updates include MQS. MQS are just private CS's.

I have an e-commerce shop that sends customers email notifications via PHP. Does this mean that "sign all" is now more appropriate for such email?
If you are sending all mail for your domain through FutureQuest via either authenticated SMTP and/or locally generated scripts and don't use QuestMail then yes.

So... "temporarily break" means... minutes? Hours? Until we report all bugs we find? Or will you be able to see and remedy all problems?

And/or do we have to add some sort of diagnostics and logging code to all scripts to let us know this has happened to particular messages?

I take it that if a message isn't sent, it's not just delayed, but lost, yes? Or no?
Minutes. The 5 minute window during which we are making this change is what is expected. If your script does not handle the case where the email is attempted to be resent, then I believe that email will be lost (I'll have to check on that...)
It would be up to your script to log or notify you of any lost or unsent emails. However, this is a 5 minute window between 12 AM and 1 AM, so effect should be minimal.

[sheila]

does this mean that scripts won't have to authenticate with the SMTP server to get a DomainKey signature?
Correct.

[songdog]

If you... don't use QuestMail then yes.

Hi Sheila. You knew THIS question was coming, so I might as well submit it now: :biggrin:

Any idea when QuestMail will be so enabled?

[sheila]

Any idea when QuestMail will be so enabled?
As has been announced elsewhere in the forums, we are working on it. I cannot give an ETA, but we will make it available as soon as we are able to.

[Stephen]

hmmm. that's more secure. but if a script sends its own DomainKey signature, will the SMTP server attempt to add another? it may not matter, of course, if the server overwrites with its own signature. but an appended signature might complicate things. i ask, because as the DomainKeys protocol gets more popular, scripts will start offering the capability to send their own signatures. of course, it owuld be simple enough in that case just to switch it off...

[Stephen]

maybe multiple DomainKeys is fine. appending them might actually be the recommended way of doing things. i see some evidence of this in the documentation for a DomainKeys signer i downloaded the other day.

[hobbes]

Thx!

[Bruce]

maybe multiple DomainKeys is fine. appending them might actually be the recommended way of doing things. i see some evidence of this in the documentation for a DomainKeys signer i downloaded the other day.That is my reading of the standards as well. They specifically give rules for choosing between multiple Domainkey-Signature: headers based on the rest of the message. As such, prepending extra signatures is valid (as long as those signatures are valid, of course).

[Stephen]

do you think there would be any chance that Crypt::OpenSSL::RSA might make an appearance on the FQ servers? i've been looking at Mail::DKIM which appears to be a decent DomainKeys signer/verifier class, and it uses that RSA class to do its encryption magic.

if not, are you using any Perl class to do the encryption for the signing, or are you using something else? i'm trying to figure out how to implement DomainKeys myself with the minimum of effort.

[JSWski]

What effect, if any, will this have on EZMLM?

[Terra]

do you think there would be any chance that Crypt::OpenSSL::RSA might make an appearance on the FQ servers?
I just tried to build that Perl module and unfortunately it is failing 2 of its 45 tests... :(

I will have to dig in and find out why, therefore I cannot provide any ETA at this time...

--
Terra
sysAdmin
FutureQuest

[Stephen]

thanks Terra. i appreciate you looking into it.

[Bruce]

if not, are you using any Perl class to do the encryption for the signing, or are you using something else?We are using the open source C library (http://domainkeys.sourceforge.net/) provided by Yahoo et al. There is no Perl code being invoked in any of the mail submission paths.

What effect, if any, will this have on EZMLM?This enhancement will include signing all email generated by ezmlm and ezmlm-idx.

[jeep]

This is really cool guys - thank you for doing this!

[Bruce]

The modifications have been completed. Normal mail appears to be working fine, but there is an bug in the ezmlm/idx modification that is causing mailing list posts to be deferred. No mail is currently being lost by this issue. We will update this thread when more information is available.

[Stephen]

We are using the open source C library (http://domainkeys.sourceforge.net/) provided by Yahoo et al. There is no Perl code being invoked in any of the mail submission paths.

i thought you might say something like that. i think you'll agree, though, that Crypt::OpenSSL::RSA is more likely to be available to the average webmaster hoping to run an application that can generate signed headers. that's the reason i am interested in it. if i had to say to someone who downloaded a mailing application "just get this C code, compile it, and..." well, i'd be talking to myself by that stage :smile:

[Bruce]

Unfortunately, I have had to revert the DomainKeys signing modification for ezmlm/idx mailing lists. There is a fundamental incompatability between the DomainKeys library and ezmlm/idx's when signed messages are distributed to a list. I am going to have to rethink my approach to this problem, as it may require invasive patches to ezmlm/idx to resolve.

The DomainKeys signing modifications for locally generated email still stand. The internal mechanisms are separate and do not directly interact. From the point of view of a DomainKeys verifier, the two domains involved (something@example.net and something@lists.example.net) are completely independant as well.

[GSK8]

This is great news and I'd like to thank the FQ team for their efforts!

I do have a question, though.

I use a program called Group Mail to send my newsletters out as they are in HTML form. Unless something has changed, I'm unable to send HTML-based newsletters using the Command 'N' Control center.

I have incorporated Habeas SWE headers and would like to know if this will conflict with any DomainKey issues.

The Habeas headers supposedly guarantee that the emails I'm sending are not spam and bypass filter systems.

For instance, they read like this:

X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to .

[johnfl68]

Are Autoresponder replies supposed to be signed as well?
Or is this a work in progress as well?? :smile:

John

[Stephen]

the Habeas solution is quite funny. i'll go with the encryption methods, thank you very much :)

http://www.welmac.org.nz/article_archives/habeas_headers.htm

[Bruce]

I have incorporated Habeas SWE headers and would like to know if this will conflict with any DomainKey issues.Unlikely. The DomainKeys signing happens at the last step before the mail is added to the queue, and so would sign everything in the header and body, including the Habeas SWE headers.

Are Autoresponder replies supposed to be signed as well?
Or is this a work in progress as well?This is a work in progress, yes.

[Juan G]

[FQuest Announce] DomainKeys Signing of Locally Generated Email
It is working now: the DomainKey-Signature header is appearing in the email notifications of my forums. Thank you very much!