> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form
> it can not be implemented in most MTAs (see below)
It wouldn't work at all in our MTA without modifications because our general
filter interface currently
2. Should this be Informational or BCP?
a: BCP, making it clear when we're insufficiently certain about
something.
Last Call will sort out any objections.
Well, I couldn't afford to go, so I can't say you're wrong, and I don't
know why I didn't see that on the list.
I
It would be very, very nice to have an ESMTP extension that
allowed sending just the headers of an email, waiting for a
2xx or 5xx response, then sending the body.
See the CHUNKING extension defined in RFCs 1830 and 3030.
CHUNKING can in theory be used to send the headers and body
OTOH, the converse is likely to be relevant to quite a lot of domains,
even if it does not apply to aol.com.
Really? Can you provide some examples of domains that use so many
subdomains for mail that it's impractical to cover the ones they use
individually? (Not counting wildcards, we
Now, I have no idea what limits were placed on this capability by
provisioning
systems. What I do know is that several customers used this feature to
create
very large numbers of subdomains. (I know this because this particular usage
exposed several bugs.)
Another thing that's
Hi Ned,
[EMAIL PROTECTED] wrote:
That said, I do have a data point to offer here.
Interesting cases. Two questions - a lot of that sounds
like stuff they did for intra-enterprise purposes that
might not be visible in the external DNS or in emails
that got sent outside - is that right or
Paul Hoffman wrote:
At 11:54 AM + 1/28/08, Charles Lindsey wrote:
I think all you need, as Frank has pointed out, is a security
consideration to the effect that
Verifiers should be aware that Bad Guys may attempt to subvert the
intentions of SSP by submitting messages that are
I would really love it if we could get past the meta-discussion of is
the multiple From: case important? to the proposals that have been made
to address the issue. These include:
1. Perform SSP checks on the domains of all From addresses in the
message, with the exception of addresses having
Barry wrote (though not speaking as chair):
I'm sympathetic to the idea that we'd like not to spend a lot of time
on an aspect that's pretty much never going to show up... on a corner
case.
That's the main idea I was trying to convey, but it appears I utterly
failed. Oh well.
Some
Tony Finch wrote:
On Fri, 18 Jan 2008, J D Falk wrote:
How many people here have EVER seen a real message (not just a test to
see if it'd work) with multiple addresses in the From: header?
I have sent messages From: multiple authors, e.g. a party invitation from
me and my wife. It was
I never have.
One of the MUAs shipped with Innosoft's PMDF product makes it easy to create
such messages. As a result I've received (and sent) many of them over the
years. Some of the old integrated office suites generated such messages and the
construct is of use in workflow environments where
[Apologies for duplicates, if any. List issues and decided to Cc
ietf-822 and ietf-smtp.]
On 12/1/07 at 3:30 PM +, John Levine wrote:
RFC 2822 section 3.6.2 describes originator fields. By my reading
it is pretty clear that a list should add a Sender: field with the
list's name
Folks,
This note is about an old topic that seems to remain unresolved. I'm posting
it to see where the working group is on the matter:
Mechanisms like OpenPGP and S/MIME essentially validate the authenticity of
content. DKIM does not. For example, a DKIM signature does not contain the
Lisa Dusseault wrote:
I share your concerns about removing rules that are already in use --
that would generally be a bad thing. However I'm interested in the
consensus around whether a warning or a deprecation statement would be a
good thing.
LWSP has a valid meaning and use, and its
discussions of multiple signatures, multiple *linked* signatures,
which could work TOGETHER to convey information, and the protocol
doesn't allow that sort of thing.
We have certainly beaten to death the issue of whether signatures can
or should survive mailing lists, an aspect of the
On Sun, 2006-07-23 at 11:53 -0700, [EMAIL PROTECTED] wrote:
My view is that DKIM is designed to provide a boundary service between
administrative domains. (I suppose we could up with a different term
than administative domain here, but since the two will align more
often than not I
Eliot Lear wrote:
Dave,
Certainly NOT the MTA, and *even* if it does change on the SUBMIT front
who cares? That's before signing, right?
Not necessarily.
What about section 8 of RFC-4409 and all those fun little changes that
can be made? We're even covered in there in 8.5.
Exactly. If you're using something other than SMTP DATA, such as SMTP
BDAT, it is conceivable that the body could wind up without an ending
CRLF
BDAT is part of the CHUNKING extension defined in experimental RFC
1830 in 1995.
Your information is out of date. RFC 1830 was superceded by
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
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
- Original Message -
From: [EMAIL PROTECTED]
To: Michael Thomas [EMAIL PROTECTED]
Cc: Mark Delany [EMAIL PROTECTED]; ietf-dkim@mipassoc.org
Sent: Friday, July 14, 2006 9:34 PM
Subject: Re: [ietf-dkim] More on naked CR canonicalization
Like it or not, you are not going to be able
In listening to the responses and looking over the text, I see
general agreement, except for Hector --- but only from a very small
set of people. Also, saying everything is optional creates an
interesting glitch in the text: currently at least one header field
must be included, and changing h=
Alternatively, we could go through working group last call,
IETF last call, and IESG push-back. For any interesting
push-back, we are probably looking at delays in the range of
6 months. (That estimate is, of course, not merely
theoretical.)
I would rather have a 6 month pushback
*If* we're going to switch away from seconds from 1970, we should use
the standardized time format described in RFC 3339: Date and Time on the
Internet: Timestamps. IMHO, using anything else would be irresponsible.
However, I don't think we have to switch.
I agree on all points.
Mark Delany wrote:
I agree that 'simple' is the easiest - in the original DomainKeys
drafts there was a sample perl implementation that took 4 or 5 lines
of code. Unfortunately because sendmail milter has a bug (that SMI
have promised to fix) some of those who are bound by milter
25 matches
Mail list logo
