On 09Feb18, John R. Levine allegedly wrote:
> RFC 822 may not have versions but 821/2821/5321 sure do.
>
> As soon as 2821 added EHLO, SMTP got service extensions and pretty
> much by their nature, those extensions are not backward compatible.
>
> Well-known examples are 8BITMIME and SMTPUTF8.
On 08Feb18, Michael Thomas allegedly wrote:
> I dunno, it's not like there isn't precedent for this. oh say, like ipv4
> vs. ipv6?
Oh I dunno. The precedent of RFC822 - the very standard we rely on - has
survived numerous upgraded and enhancements over a 36 year period and managed to
do just
> True, but not very interesting. In my spamassassin example, the outside
> code knows nothing about DKIM versions, it just sees a dkim-signature
> header and sends it to the DKIM library.
>
> The point of a v=2 flag is to ensure that old v=1 code doesn't
As a practical matter haven't you
On 08Feb18, John R. Levine allegedly wrote:
> On Thu, 8 Feb 2018, Mark Delany wrote:
> > Heh. I'm still waiting to hear a good reason as to why "v=" exists at all -
> > apart
> > from exposing brittle parsers which mistakenly expect it to show up as the
> &
> "v=1" doesn't have to come first. It just usually does. I think there was
> a version of RFC4871 that did that, but then when challenged we couldn't
> come up with a good reason to keep it that way.
Heh. I'm still waiting to hear a good reason as to why "v=" exists at all -
apart
from
On 06Dec17, Suresh Ramasubramanian allegedly wrote:
> The pledge idea isn???t terribly novel either
>
> Anne Mitchell used a habeas haiku
Gosh. The Haiku. How could I have possibly forgotten that beauty! But,
if you really want to intimidate spammers with poetry I recommend the
very effective
On 05Dec17, Steve Atkins allegedly wrote:
>
> I thought this might be of interest to DKIM implementers.
> The Asserted Patents share a common specification.
Did the claimants vacuum up the IP of the now defunct Goodmail? Reads
somewhat similar to what they were once trying to sell. Particularly
Hi Murray.
> RFC6376 and even RFC4871, but now it's apparently happening
I'd be interested to hear about the actual scenarios. Are the targeted
users somehow given an indication that the email verifies and it's
from a credible domain and yet it contains a malevolent payload?
This sounds like
On 27Jan15, A. Schulze allegedly wrote:
Hello everybody,
Murray encourage me to ask here:
https://tools.ietf.org/html/rfc6376#section-3.3.3 say
Signers MUST use RSA keys of at least 1024 bits for long-lived keys.
and
Verifiers MUST be able to validate signatures with
keys
I admit that I also got confused a few times while working on the DKIM
documents and keeping it straight as to which section was referring to
which set of arguments. Having them use different values and different
tags for items that were conceptually the same was an unfortunate aspect
aspect
DKIM should be viewed as a Work-In-Progress still missing a viable
policy layer.
+1. But 5+ years WIP? :) It wasn't rocket science.
Well, 7+ years ago it was suggested that Domain policy is nascent
with the stated expectation that MARID would soon develop something
comprehensive to
On 22Jul11, O'Reirdan, Michael allegedly wrote:
Chaps
I would like to bring to your attention and solicit comments on the following
draft.
http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00
Hi Mike. On first glance it doesn't look like much of this document is
On 16May11, Alessandro Vesely allegedly wrote:
On 16/May/11 15:41, John R. Levine wrote:
http://www.opendkim.org/stats/report.html#hdr_canon says
Header canonicalization use:
canonicalization count domains passed
simple 6536886786591938
relaxed
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset=us-ascii
are completely equivalent
DKIM has never tried to understand the semantics or syntax of each
header. First off, doing this properly is very hard as there are a
large number of equivalent
On 16May11, J.D. Falk allegedly wrote:
On May 15, 2011, at 9:42 PM, Barry Leiba wrote:
The author can be a human using an MUA (Mail User Agent) or
an automated mail robot with an MTA.
I don't see that automated mail robot with an MTA is right at all.
But I see what you're
On 31Mar11, Franck Martin allegedly wrote:
Silly question (?):
Knowing that many mailing lists add [topic] at the beginning of the Subject
line, what if DKIM was set to ignore that part when signing/verifying?
Would it help to solve the problem of broken signature thru mailing lists?
As you see, Sean has kept DKIM. Stephen will be up there with me on
the Monday in Prague, for his last meeting as working group chair;
Gosh. And it only seemed like yesterday ... or was it the day before
yesterday ... that Stephen came on board as a chair.
Many thanks to Stephen for doing a
On 28Feb11, Murray S. Kucherawy allegedly wrote:
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Monday, February 28, 2011 10:35 AM
To: Murray S. Kucherawy
Cc: Michael Thomas; Hanno B?ck; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] ECC (was
Forgive me for a bit of an aside, sortof.
A lot of people have long used the Postal Service analogy of being
able to supply an arbitrary return address as a justification for
doing the same in email (DC I'm looking at you, buddy).
So did anyone catch the news today that UPS.com are planning to
On Wed, Nov 24, 2010 at 10:57:58AM -0800, Douglas Otis allegedly wrote:
On 11/24/10 9:01 AM, Dave CROCKER wrote:
On 11/23/2010 3:14 AM, Ian Eiloart wrote:
Actually, they're complementary. In places where DKIM fails
(mailing lists rewriting messages), SPF can succeed. And in places
On Sat, Nov 20, 2010 at 11:49:36AM +0900, Tsuneki Ohnishi allegedly wrote:
Hi to all,
I am Tsuneki Ohnishi and I would like to let you know
that DKIM Japan(dkim.jp) has just been set up as of
Nov 15, 2010.
Welcome, Tsuneki, glad to have you join. It's great news to hear of
such
The universe of email is replete with software that forgives
messages which do not conform strictly to the grammar that defines
what valid email looks like. This is a long-standing practice known
informally as the robustness principle, originally coined by Jon
Postel: Be conservative in what
Those are two different changes. My own sense is that each has some
controversy, with the first being pretty substantial and with the first
having
some significant counter-proposals.
My preference is still that verifiers reject messages that are likely to
display misleadingly in
On Wed, Oct 20, 2010 at 09:38:04PM -0700, Murray S. Kucherawy allegedly wrote:
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Wednesday, October 20, 2010 5:08 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] double header
On Wed, Oct 20, 2010 at 01:41:03AM -0700, SM allegedly wrote:
At 17:53 19-10-10, Mark Delany wrote:
In a DKIM world a list server could reasonable use DKIM to bypass this
confirm sequence and make your life a bit simpler. Perhaps it relies
on Authentication-Results or somesuch. In any event
On Mon, Oct 18, 2010 at 06:07:15AM -0700, Dave CROCKER allegedly wrote:
On 10/18/2010 3:31 AM, Ian Eiloart wrote:
--On 15 October 2010 11:53:51 -0400 Dave CROCKERd...@dcrocker.net wrote:
On 10/15/2010 11:40 AM, Mark Delany wrote:
Well, if you want to introduce semantic changes why
result of software layers that render those bits. DKIM has no
control over that rendering process.
Really? Do you mean doesn't or shouldn't or can't?
Apropos layering violations: are we saying that having a UA inject
message 'A' via a DKIM layer into the mail stream, and then having
some
On Sat, Oct 16, 2010 at 02:54:13PM +1200, Franck Martin allegedly wrote:
I found today this patent:
US PATENT 7487217
http://www.docstoc.com/docs/57449330/Network-Domain-Reputation-based-Spam-Filtering---Patent-7487217
but then it seems prior art existed in the form of DKIM (which was
Breaking that down further: Of the 8,219, 6,614 (80.4%) were author domain
signatures, so the rest were presumably list signatures (or something else).
57 of them failed even in the presence of an l= tag.
More work for Murray. Distribution of the l= values? Particularly l=0
Mark.
I thought the What DKIM does thing was a long-dead horse, as we'd
long ago reached consensus that what DKIM does is provide a stable
identifier on the message, and nothing more. That makes this
assertion inapposite.
I think perhaps now would be a good time to make that explicit,
since a
to:
section
title=Introduction
tDomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by
associating a domain name xref
target=RFC1034 / with the message.
What is essential is that it perform the task of validating and delivering a
signing domain that is associated with a collection of bits. Anything that
defines how to do this is essential. Anything that can make this break needs
to
be covered, especially if there are ways to protect
On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote:
What is essential is that it perform the task of validating and delivering
a
signing domain that is associated with a collection of bits. Anything that
defines how to do this is essential. Anything that can make
On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote:
On 13/Oct/10 20:45, Scott Kitterman wrote:
On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
If we can extract DKIM from the equation entirely and the problem remains,
how is it a DKIM
In that light, taking an additional step wrt duplicate headers (or
malformed 2822 in general) is still in the same layer as the verifier.
My objection isn't so much layering within the software, because I know that
gets mushy real quick, but layering among the protocol specifications.
I'm scratching my head to see if there is any advice we can offer to make
signing and verification more robust while not changing the behavior of
existing code for normal (for some definition of normal messages).
A) You have to sign either all occurences of a header or none of them, and
I don't think that's a fair characterization. It is simply wrong to try to
deal this problem in DKIM. For example, a bug in the TCP stack that causes
malformed data to arrive in an application which in turn causes something
visible and unexpected, possibly even something dangerous, to
On Tue, Oct 05, 2010 at 10:31:32PM -0400, Dave CROCKER allegedly wrote:
PS: Note that I'm saying nothing about whether or not this
issue should be mentioned in 4871bis.
FWIW:
Adding to a specification, by trying to protect against behavior that is
already
illegal is wasteful,
That this is not in 4871 seems to be mostly a WG assumption that
should be made explicit.
I think several of us thought it was in there, but on review it apparently
was indeed lost somewhere along the way. We've certainly, as I understand
it, been proceeding from that assumption for a
On Thu, Sep 30, 2010 at 06:51:44PM -0700, SM allegedly wrote:
Hello,
I have a few comments about
draft-ietf-dkim-implementation-report-01.
Me too.
Thanks very much for writing this up, Murray. Very enlightening. And
that Alt-N - a relatively small company - hosted an event for the big
guys
http://feedbackloop.yahoo.net/
Step 2 doesn't help. (yes, you can put * for all selectors, but asking for
one when it isn't really needed leads to FUD).
A selector can of course be in a sub-domain format, such as
september.dialup._domainkey.example.net
I wonder if they considered letting
On Sat, Sep 04, 2010 at 01:41:41PM -0700, Steve Atkins allegedly wrote:
Do we have any thoughts on 1. how often keys might sensibly be
rotated and 2. how long public keys should remain visible after the
private key has been rotated out?
I believe the general thrust is that DKIM keys are
As a part-time MTA developer I am not confused. The DKIM signature
provides a simple piece of trace information (I handled this mail)
that is cryptographically bound to some header and body content.
Yes. And that the obverse is possible: I didn't handle this mail.
I don't see how
Right, but emphasize that the granularity is a signing domain -- it is
not and cannot be a way to attribute mail to individual people.
Unless you have reason to believe that the signer is taking steps to ensure
that the sender information is accurate. I'd say that a DKIM signature from
On Fri, Aug 20, 2010 at 11:55:40AM -0700, Murray S. Kucherawy allegedly wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Hector Santos
Sent: Friday, August 20, 2010 11:42 AM
To: ietf-dkim@mipassoc.org
Subject:
hmm, I am surprise that I have to be put into an awkward
position to explain what binding means here as digital signature
term in what I thought was a technical qroup. Very odd.
Hector. You are too funny.
You miss the subtlety and then you assume the OP is inexcusably
ignorant.
I
A) Use the From: address (or something that identifies the contributor)
as the primary sort criterion
B) Use the List-ID: (or something that identifies the list) as the
primiary sort criterion
C) Something else
C) The 821.RCPTTO address.
Which probably means this straw poll really is
So my view of the service being discussed here isn't one where some
guy in upstate NY claims to have full knowledge of which domains
DKIM-sign all their outbound email. Rather, it's a service where the
manager of the service uses claims made by the sender about whether
they sign all of their
On Feb 24, 2010, at 5:51 AM, Michael Thomas wrote:
I'm sort of dubious about this. Unless you're using z=, your chances
of
figuring out why something broke are slim to none. With z=, your
chances
of figuring it out are merely slim.
Mike, with far too much experience at that
It got a
The thing that I'm skeptical about is that an automaton can be
programmed
to do this sort of analysis with any sort of accuracy. We're talking
about
a potential flood of reports coming in, I assume, so I doubt we're
all going
to be putting out job reqs for DKIM Signature Breakage
On Oct 29, 2009, at 9:11 AM, Dave CROCKER wrote:
I'm guessing the incentive for all of this is to reduce bandwidth,
otherwise why not just issue the 4XX/5XX after the DATA/. sequence
rather than invent a new mechanism to issue the same response at the
envelope end of the transaction?
On Aug 3, 2009, at 10:31 AM, Douglas Otis wrote:
On 8/2/09 1:06 AM, Mark Delany wrote:
On Aug 1, 2009, at 9:14 PM, Franck Martin wrote:
But is ICANN supposed to clean all these random valid domains?
You half-joke, but one of the arguments we presented to the FTC
back in
2003 or so
On Aug 1, 2009, at 9:14 PM, Franck Martin wrote:
But is ICANN supposed to clean all these random valid domains?
;)
You half-joke, but one of the arguments we presented to the FTC back
in 2003 or so regarding spam was that we had an opportunity to
regulate issuance of domain names. If not
If a site wanted to revoke instantly any signature previously
generated with rsa-craphash, couldn't it just revoke its old keys
and generate new keys, and begin signing with rsa-goodhash?
Yes, it is a design feature of DKIM that an operational crypto error
can be instantly revoked by merely
DKIM-Signature Header tags
x: Signature expiration
l: Body length count
Removal of these would be a show stopper for me. In fact, overall,
anything that is SECURITY related should be protected from removal
proposal.
Do you mean anything that is security related or do you mean
Note: ADSP is incompatible with valid DKIM usage in which a
signer
uses i= with values that are not the same as addresses in
mail
headers. In that case, a possible workaround could be to add a
second DKIM signature a d= value that matches the Author
Address, but
On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins
st...@wordtothewise.com wrote:
Did we already look at this idea and discard it before we settled on
using a DNS query for every email received?
Discussed, not discarded. AFAIR, the general feeling is that
Lookups are cheap today.
Outside of DNS query related technical issues, the first
operational repercussion is the lost of handling legacy mail. We
need to use an standard anchor something we know will always be
there, which as it is now, is the From: domain lookup.
For those subset of folk who want to do
On Jan 28, 2009, at 5:22 PM, Suresh Ramasubramanian wrote:
On Thu, Jan 29, 2009 at 2:22 AM, Douglas Otis do...@mail-abuse.org
wrote:
There will be work involved when dealing with opaque i= values when
assessing reputations. Any amount of consolidation of this
information will
induce a
On May 23, 2008, at 6:05 PM, Arvel Hathcock wrote:
A compromise proposal has been laid out which is to remove the
NXDOMAIN
step from the algorithm but add text defining ADSP as applicable
only to
domains which actually exist in DNS. This removes the need for
ADSP to
specify how (or
On Mar 24, 2008, at 10:18 PM, Dave Crocker wrote:
Jim Fenton wrote:
Section 4.1 paragraph 3 talks about the service type (s=)
constraint in
key records, and goes on to say that it is helpful when delegating
signing authority. s= was included to provide expansion capability
should, at
On Mar 24, 2008, at 10:30 PM, Jim Fenton wrote:
The current utility is that, while extensions can be added any time,
constraints need to be added up front.
Okay, I'll bite. Why is this a good idea? By way of contrast, when an
A RR is added to a DNS zone saying what address to use, no
On Mar 25, 2008, at 9:00 AM, Jim Fenton wrote:
Dave Crocker wrote:
Jim Fenton wrote:
Dave Crocker wrote:
You further seem to indicate that s= is not currently useful but
would be
if it listed other services. (I well might be misunderstanding
this
part
of your text.) In any event,
It also limits the ability of an external party that has been
delegated a key for a particular service to (mis)use that key for
other, unauthorized services.
That's probably the best reason for it. In any event, this is surely
moot at this stage. Most protocols end up with unused or
A minor typo in one of the examples has been pointed out by one of
our implementers and I don't really know the process for fixing this.
Can someone explain this for me? (Chairs maybe).
The typo is the absence of v=1 in the example on page 25. No big deal.
Mark.
On Mar 12, 2008, at 8:20 PM, John Levine wrote:
Hello? Why? You mean it's out of line for me to point out that
people might not have appreciated the full implications of what they
were arguing about?
Based on the discussion I listened to in the DKIM session, I am
confident that people who
On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:
Mark Delany wrote:
On Jan 24, 2008, at 8:37 AM, Wietse Venema wrote:
Summary of proposal:
All text that causes SSP to be applied to an already-signed
message
needs to be removed.
I would take this further: remove all text that says when
On Jan 24, 2008, at 8:37 AM, Wietse Venema wrote:
Summary of proposal:
All text that causes SSP to be applied to an already-signed message
needs to be removed.
I would take this further: remove all text that says when to apply
SSP. Instead, provide text that states the contribution that
On Nov 9, 2007, at 7:46 AM, Dave Crocker wrote:
[EMAIL PROTECTED] wrote:
A better question is how many domains will move signing into
production
without the testing flag, then fix the inevitable issues.
Given that most protocols do not have a 'testing' flag -- and they
manage to move
On Oct 22, 2007, at 1:37 PM, Jon Callas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So if he said i=subdomain.example.com, then surely the From/Sender
can be expected to be from that subdomain; and if he said
[EMAIL PROTECTED], then surely recipients can assume that
'someone' had
maybe Eric could still do a s/LWSP/[FWS]/g in AUTH48
eliminating LWSP everywhere (?)
Absolutely not. This is a technical change.
It's IMO more in the direction of an erratum. Nobody
could claim with a straight face that they need lines
consisting only of white space for their folding
Dave Crocker wrote:
The proposed mechanism incurs an additional lookup for every signed
message.
Whatever algorithm policy you embed in a separate SSP can just as easily
be embedded in the Selector of the weakened key.
But maybe that just means I don't get any of the discussion about
Charles Lindsey wrote:
Anyway, here is some wording:
The simple body canonicalization removes empty lines from the end
of the
body until either the last line is non-empty, or no lines remain. An
empty
line is a line of zero length after removal of any terminating CRLF. If
the
Charles Lindsey wrote:
Now apply simple canonicalization to all those cases, using:
In more formal terms, the simple body canonicalization algorithm
converts 0*CRLF at the end of the body to a single CRLF.
Making the entirely reasonable assumption that body means exactly what
RFC 2822
On Wed, Aug 09, 2006 at 10:30:21PM -0400, Tony Hansen allegedly wrote:
Stephen Farrell wrote:
Michael Thomas wrote:
Tony Hansen wrote:
add RFC2822.Sender
I'm not the chair, but I've seen considerably less consensus about
anything other than rfc2822.from. I'm frankly not sure I
On Sun, Aug 06, 2006 at 10:53:21PM -0700, Michael Thomas allegedly wrote:
Hector Santos wrote:
Even then, the main issue are the potential damages that are being
ignored.
My wife said it best when asked why even the BIG companies like WALMART,
YAHOO, CISCO, AOL.COM, BIGBANK should
If I choose to deliver unsigned mail that purports to be from a domain that
says
it signs everything, but I mark it up with flashing lights that say spoofed
do
you want that to be a protocol violation? What about my choosing to send it to
my sysadmin for special handling for spoofed mail?
From: Dave Crocker [EMAIL PROTECTED]
why is is not sufficient to leave things with the simpler -- albeit
more passive -- stance that a sender talks about themselves but
refrains from telling the evaluator what to do with the information?
Yes, that is at odds with a classic model of protocol
On Sat, Aug 05, 2006 at 04:57:23PM -0700, Dave Crocker allegedly wrote:
John L wrote:
Your assertion in the subject is an opinion. I find the statement below
to be useful.
I think we have a subtle point here.
I sign everything so please discard unsigned mail apparently from me
On Sat, Aug 05, 2006 at 07:05:16PM -0400, Hector Santos allegedly
Having SSP still in play will not serve your business well.
Hector. Most of us on this list are in the email business - including
you - as I understand it. If we start slinging arrows at anyone who
has a business connection, most
On Fri, Aug 04, 2006 at 06:44:34PM -0400, John L allegedly wrote:
I cannot see how SSP can do anything but make false positives more
likely. The real question is whether the gain in eliminating harmful
mail is worth the occassional false positive.
I guess I'm a little confused about the
On Sat, Aug 05, 2006 at 03:40:58AM -, John Levine allegedly wrote:
I can't gather requirements if I can't make any sense of what you're saying.
That's a reasonable concern.
The fog around SSP is so opaque that I'm really wondering if it
wouldn't make more sense to punt and wait for
On Wed, Aug 02, 2006 at 09:24:40PM -0700, Dave Crocker allegedly wrote:
If I used a skanky ISP, rather than the stellar songbird.com, how could my own
wonderful reputation overcome the awfulness of the reputation of my ISP?
Er, unless the ISP is truly skanky and abuses access to your DNS, then
NS delegation works for exactly one provider. This is probably just
fine for a pretty reasonable swath of small business, but it really
doesn't addresss the whole spectrum. For example, if I outsource my
mail to isp.com, I'm also pretty likely to outsource my email campaigns
to
On Thu, Aug 03, 2006 at 08:14:19AM -0700, Dave Crocker allegedly wrote:
In other words, I think that fate-sharing is inherent here, where two
different
domain names can be identified.
Why would your ISP be identified and, even if it is, why would its
signature, as a third-party, be
On Wed, Aug 02, 2006 at 08:02:54PM -0700, Dave Crocker allegedly wrote:
[Starting a new thread to focus on a one aspect]
Outsourcing for mail sending is already common, so it seems likely that
delegating signing would be, too.
But my question is why it is better to have a delegation of my
On Mon, Jul 31, 2006 at 09:59:19AM -0400, [EMAIL PROTECTED] allegedly wrote:
You believe both and apply a receiver policy determined by yourself that
will handle a message with an anomaly,
I'm with John on this. I don't see any merit in constructing a system
that allows anomalies soley for the
I guess I had been making the assumption that an SSP query is only
necessary on a verification failure. Some of the conversations seem to
suggest that an SSP query will be needed regardless of the success of
the verify. Is that the case at all? The uncommon case? The common
case?
Mark.
On Sun, Jul 30, 2006 at 03:15:57PM -0400, Hector Santos allegedly wrote:
I think not understanding something does not give those who do, those who
has put in the time to help engineer this all out, from a real production
standpoint, the benefit of the doubt.
Thanks, you demonstrate the point
On Fri, Jul 28, 2006 at 08:01:18AM -0700, Michael Thomas allegedly wrote:
Hector Santos wrote:
One initial and obvious design consideration is length limit related. One
reviewer did suggest some 'include' concept or protocol to access large
list.
I'd venture to say that include ala SPF
On Fri, Jul 28, 2006 at 09:18:35AM -0700, Michael Thomas allegedly wrote:
Perhaps a better mechanism is to just completely disallow jumps from
one domain namespace to another, ie that any indirection must take place
in the subtree of the consulted domain, and that it's just, say, an n stage
On Fri, Jul 28, 2006 at 02:46:32PM -0700, Jim Fenton allegedly wrote:
You need to be open to other possibilities and make system easily
extendeable to other identities. My preference would be to encode
identity in the lookup path, so instead of doing lookup on _policy
it would actually be
On Thu, Jul 27, 2006 at 03:02:55AM -0500, Arvel Hathcock allegedly wrote:
Especially since one can achieve that same effect by having an SSP
that says I sign everything and then don't sign any email.
One can achieve the same effect perhaps but it's not as easy to
understand or explain:
On Wed, Jul 26, 2006 at 04:30:15PM +0100, Stephen Farrell allegedly wrote:
I've always wondered why dkim is taking on the task of supporting
I don't send mail since the statement makes no reference to
signatures at all. Arguably, that's something that should be dealt
with by someone else, who
On Wed, Jul 26, 2006 at 12:08:00PM -0700, Dave Crocker allegedly wrote:
Folks,
I've heard a number of different groups say that they plan to make semantic
distinction based on selector. For example, they intend to send transaction
mail under one selector and marketing mail under another.
On Wed, Jul 26, 2006 at 05:06:09PM -0700, Steve Atkins allegedly wrote:
No. Invalid signatures are to be ignored. In the case of a
mailing list, an invalid signature may be common for many years.
Only when there is an assertion that mail is never sent, can mail
be outright rejected,
On Mon, Jul 24, 2006 at 10:21:51PM -0400, Hector Santos allegedly wrote:
- Original Message -
From: Stephen Farrell [EMAIL PROTECTED]
To: Hector Santos [EMAIL PROTECTED]
This can produce an interesting result with the DKIM signature
calculated as valid but with feedback that the
On Tue, Jul 25, 2006 at 01:02:05AM -0400, Hector Santos allegedly wrote:
For example:
--pWyiEgJYm5f9v55/
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
can get turned into this:
--pWyiEgJYm5f9v55/
Content-Type: image/jpegContent-Transfer-Encoding: base64
Is that
On Wed, Jul 19, 2006 at 07:30:50AM -0700, Michael Thomas allegedly wrote:
Tony Hansen wrote:
This not a problem when using DATA. Check 2821 section 4.1.1.4; the
ending crlf.crlf was clarified as being the trailing crlf of the last
line of the message followed by the terminator sequence.
On Wed, Jul 19, 2006 at 11:00:29PM -0400, Tony Hansen allegedly wrote:
Paul Hoffman wrote:
At 12:35 PM -0700 7/19/06, Douglas Otis wrote:
To gracefully allow removal of this feature, should that become
required, the sense of the s flag and the corresponding defaults
should be inverted as
1 - 100 of 208 matches
Mail list logo
