- Original Message -
From: "John L" <[EMAIL PROTECTED]>
To: "Michael Thomas" <[EMAIL PROTECTED]>
> I have never come across an application that depended on naked CR or LF
> being passed through SMTP.
Is QMAIL strickly a SMTP to SMTP transport system?
Does QMAIL only accept feeds from SM
> In the months since we went live with probably hundreds of millions
> of messages passing through our signers/verifiers, this is the only thing
> that I've seen with any consistency that breaks the body with simple.
How many of those were signed though? And what was the intent of the
signer wrt
On Sun, Jul 16, 2006 at 09:35:22PM -0700, Michael Thomas allegedly wrote:
> John L wrote:
>
> >
> >>>My strong suggestion is to say that if you want your DKIM signatures
> >>>to interoperate, you should only sign compliant mail.
> >>
> >>That's completely unhelpful.
> >
> >
> >Just in case you mi
that's a private network, not SMTP. I am utterly unable to imagine why an
IETF standard should require DKIM to handle such messages when we all know
that the only reason they happen is software bugs, and it's already common
practice to fix them up at a relay.
Incorrect. They could be applicat
John L wrote:
My strong suggestion is to say that if you want your DKIM signatures
to interoperate, you should only sign compliant mail.
That's completely unhelpful.
Just in case you missed it the last three times I said this: make the
message compliant, then sign it.
I guess you miss
In the months since we went live with probably hundreds of millions
of messages passing through our signers/verifiers, this is the only thing
that I've seen with any consistency that breaks the body with simple.
Right. So fix the message, then sign it, thereby making the message and
signature
John Levine wrote:
In our testing at Cisco, we are seeing a small but significant number
of failure mainly due to various system bots that send naked CR's in
a message.
Yeah, there are a lot of badly written MUAs.
What I have found is that at the very least, sendmail and Ironport
han
>In our testing at Cisco, we are seeing a small but significant number
>of failure mainly due to various system bots that send naked CR's in
>a message.
Yeah, there are a lot of badly written MUAs.
> What I have found is that at the very least, sendmail and Ironport
>handle these two cases differ
Scott Kitterman wrote:
On Sat, 15 Jul 2006 08:10:50 -0700 Eric Allman <[EMAIL PROTECTED]>
wrote:
I have just submitted draft-ietf-dkim-base-04 to internet-drafts for
publication. An advance view can be found at
http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-04.txt
http://www
At 1:25 PM -0700 7/16/06, Scott Kitterman wrote:
Is it normal to do a last call on a document with known open
issues?
Yes, just as it is normal to wait for all known issues to be fixed.
It's up to the WG chairs and the WG.
___
NOTE WELL: This list o
On Sat, 15 Jul 2006 08:10:50 -0700 Eric Allman <[EMAIL PROTECTED]>
wrote:
>I have just submitted draft-ietf-dkim-base-04 to internet-drafts for
>publication. An advance view can be found at
>
>http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-04.txt
>http://www.neophilic.com/~eric
I wrote:
>> I am prety sure that historic has never been applied to a specification that
>> was
>> not previously an IETF standard.
>>
>
> It's happened once before, somewhere in the 1xxx series. I forget which
> document, but it was recently discussed on what I believe was the IETF
> list
Mark Delany wrote:
> As long as the RFC numbers turn out in the right order. Would it
> confuse folk if the Information had a bigger number than DKIM?
>
>
I don't know. I think the simple approach is to send an email to the
RFC Editor to see that this doesn't happen. I'm pretty confident they
Dave Crocker wrote:
> What is the reason for Historic, rather than Informational?
>
> I am prety sure that historic has never been applied to a specification that
> was
> not previously an IETF standard.
It's happened once before, somewhere in the 1xxx series. I forget which
document, but i
Dave Crocker <[EMAIL PROTECTED]> writes:
> What is the reason for Historic, rather than Informational?
>
> I am prety sure that historic has never been applied to a specification that
> was
> not previously an IETF standard. The usual means of labeling an RFC that
> specifies a popular, propriet
15 matches
Mail list logo
