software.
-
Sincerely
Hector Santos
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Dave CROCKER wrote:
Not only is it confusing, it's wrong. Wildcard records work just fine when
the
wildcard is below the _domainkey label, e.g. *.foo._domainkey.example. They
work
less fine in other cases.
The modified text I offered is intended to handle several coverage problems
the the validity of the return
path is only when the bounce is necessary. I don't agree with that.
IMV, at the precise SMTP moment it is issued at MAIL FROM:, it *MUST*
be valid at the time point.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
.
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
conditions and its output is well defined and described with a view on
being a feed for possible message filters/handlers.
--
Sincerely
Hector Santos
http://www.santronics.com
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
the TA process.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Charles Lindsey wrote:
On Thu, 04 Nov 2010 02:04:16 -, Hector Santos hsan...@isdg.net wrote:
It is (A) that is most important here and this is where the corrective
text should be added. The original ISSUE Posting included proposed
text to follow the last header paragraph in Section 5.4
is an integrated one and since this belated
highlighted ISSUE has now shown it is also a problem for non-DKIM
streams, integrators are now smarter about the issue and will most
systems will begin to do more RFC5322 checking prior to any DKIM
processing or display to users.
--
Hector Santos, CTO
http
.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
another way to provide the
concept of absolving domain responsibility.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
day
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
of a focus to protect exclusive domain signed messages from
abuse.
I highly recommend that the term is removed from the specification.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates
about 100. Now I
just need better logs to figure out what message that was.
What is your goal here?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
provisions for DKIM
verifiers. A real POLICY protocol with 3rd party considerations is
really the only thing that can help resolve this problem. Even
Reputation Vendors can help here but they need to support POLICY too.
Instead, the pressure has been to eliminate it.
--
Hector Santos, CTO
Sections 3.5 and 5.4
for further discussion of this mechanism.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
signature by including two copies of the header fields about
which they are concerned in the signature h= tag e.g. h= ...
from:from:to:to: subject:subject See Sections 3.5 and 5.4
for further discussion of this mechanism.
--
Hector Santos, CTO
http://www.santronics.com
http
and will promote another
round of reviews or something like that. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Steve Atkins wrote:
On Oct 26, 2010, at 1:49 AM, Hector Santos wrote:
Murray S. Kucherawy wrote:
8.14 Malformed Inputs
DKIM allows additional header fields to be added to a
signed message without breaking the signature.
This tolerance can be abused..
DKIM does not allow additional
John,
The reported issue was about *mixed* TXT usage caused by wildcards.
And it amounted to a large Domain Hosting vendor ONLY offering this
for spf:
*.example.com IN TXT v=spf1 ..
And that created mixed query results after adding DKIM related TXT
records.
The proposed
statement of validity for the hash bound 5322.From which
is another way of saying that there is a market of originating domains
that decide what is signed and what signer domain will be used to
represent them in some future out of scope reputation or currently
possible VBR feeds.
--
Hector Santos, CTO
, the majority of the industry can grasp and feel
the issues regarding a 5322.From and can better understand the idea
that DKIM might be a technology to help protect it.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Mark Delany wrote:
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
forward technical correction
description which may include code change requirements.
Thanks for listening.
--
Hector Santos, CTO
http://www.santronics.com
Barry Leiba wrote:
We seem to be bush-whacking again, rather than staying on the trail.
I don't mind (actually I like) some level of general
, then
there begins some truth to the statement.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
what is
fundamentally necessary.
The DKIM component MUST check its input and at least one independent
API has done so (on the verify side for 5322.From only). It could not
pass the buck to 822/2822/5322 message generators or verifiers.
--
Hector Santos, CTO
http://www.santronics.com
http
this, a DKIM is an
independent RFC 5322 Protocol Technology - therefore it inherent all
the design requirements to make sure that GIGO (Garbage In, Garbage
Out) does not occur.
Lets fix the DOC BUG and be done with it - thats forward progress.
--
Hector Santos, CTO
http://www.santronics.com
http
, it was DKIM
signed and exported to the spf-discuss mailing list. The list server
than broke and resigned it and when the copy came back to us, it will
DKIM verified and put into the newsgroup area.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
John R. Levine wrote:
Here's another batch of spam with extra From or Subject
lines. I see the same thing as last time, the extra
subjects are all the same, and the extra From lines look
like bugs, not attempts to evade filters.
The spam with 6,981 From lines is impressive in a wacky way.
of non-DKIM supportive mail
pickup host.
Overall, the point is the backend has complete control of what to
display for its online access user interfaces. But for the offline
MUA, there wasn't muuc we done to give them trust and avoid repeating
the DKIM verification.
--
Hector Santos, CTO
http
These are not MSA or MDAs so its a different set of assumed preconditions.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org
the deterministic bits of DKIM well
defined - valid input and it needs to check it probably is only thing
left.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org
.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Charles, I was showing what already is written and suggesting that it
might need clarification.
Charles Lindsey wrote:
On Sat, 16 Oct 2010 05:09:53 +0100, Hector Santos hsan...@isdg.net wrote:
This probably means that it should clarified what that 5.4 sentence
means and also the next
SM wrote:
Hi Hector,
At 09:28 16-10-10, Hector Santos wrote:
From an IETF procedural angle. :)
I'll comment on how I read what the WG Chairs said in general terms. If
you believe that the process followed is not fair, you could discuss the
matter with the WG Chairs. I'll quote
is what I signed semantics, one could do the
following:
[SNIP] [SNIP]
I see you have a funny bone in you. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http
Online or Offline mail readers who require (and don't
even think about it) that the backend mommy give them clean food to
eat - not poison, dirty food.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL
.
Their solution was only on the verification side with an added
requirement that all 5322.From be signed - the default behavior.
So any belated injection of a 5322.From header would invalidate the
signature which I believe will cover the majority of the loophole.
--
Hector Santos, CTO
http
FWIW, the telnet mail interface typo fix should be:
telnet bbs.winserver.com
--
HLS
Hector Santos wrote:
I'm a MUA author of BOTH types and people forget that there are TWO
kinds here. We have:
Console based Mail Reader/Writers Online Interface (Dialup/Telnet
of Policy and b)
greater allowance for unrestricted resigners and participants were
providing
input that there was an engineering problem with this.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
the basic ideas as above:
- DKIM SHOULD|MUST checks it main inputs
- Receiver MTA SHOULD|MUST check RFC5322 more strongly with
a specific guidance on what it should focus on in order for
DKIM to be protected.
--
Hector Santos, CTO
http://www.santronics.com
http
to sign and verify. So it needs a quick by the way
paragraph regarding a special exception for 5322.From against the use
the last field rule in the previous paragraph.
But in the name of moving forward, Jim's text does the job.
--
Hector Santos, CTO
http://www.santronics.com
http
.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
SM wrote:
You can tell me if I am wrong here cause I am trying to make sure I
It is not up to me to determine whether you are wrong. :-)
From an IETF procedural angle. :)
1) Verifier TXT record parsing
I checked for this, but did not find it, but was a quick scan.
If the DKIM specs
feed them and they can't
exist without a backend.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy wrote:
Levine wrote:
Aw, come on. How many millions of people still use Outlook Express on
Windows XP? Switching MUAs is painful, people rarely do it.
...meaning MUA developers won't bother to do something about
it once the attack is plainly visible and they're used
Folks, I really think we should use the opportunity to add a note
about DKIM adopters having potential DNS setup issues due to wildcard
SPF records.
When section 3.6.2.1, SPF was probably still growing and not wide
spread with Web-Based DNS managements from ISPs. Today, a special
Add SPF
Steve,
I believe its about protocol consistency. While the main focus is
DKIM progress, its issues and resolutions are related to ADSP as well
as its a WG product as well.
For example, ADSP implementations now know that they need to make
there is only one 5322.From as well. Like most
OFF and take in all the input and try to block
them in their inputs.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf
resigning strips the original.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
SM wrote:
This is just to jump start suggested text. Others can add/change
whether they think helps:
The DKIM public key TXT record MUST not be mixed or merged
with other TXT records, i.e. SPF. In addition, make sure other
TXT records with Wildcards do not conflict with DKIM
not represent an emergency, but there is a shape or limits
that tells you something is not right and alerts need to be signaled.
For DKIM, we can only do this with Domain Expectations to help
verifiers and local policy be molded.
--
Hector Santos, CTO
http://www.santronics.com
http
Murray S. Kucherawy wrote:
There might be a better way to characterize it, but I think the answer comes
from the errata RFC upon which we reached consensus a while back: The primary
payload delivered by a DKIM validation is the validated domain name.
Reputation, for example, would be
of at the
moment) wasn't present.
For our DKIM implementation, it will fail to sign and fail to verify.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
of the signed headers.
The spec says
5.4. Determine the Header Fields to Sign
The From header field MUST be signed (that is, included in the h=
tag of the resulting DKIM-Signature header field).
That means to me it MUST exist to be signed.
--
Hector Santos, CTO
http://www.santronics.com
http
see what you mean, because if it means that you
have to add h=from without a real 5322.From, then a signature might
be signed and be technical DKIM valid but only against those systems
that are not enforcing a 5322.from header.
--
Hector Santos, CTO
http://www.santronics.com
http
SM wrote:
That text adds a requirement in an informative note.
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those with currently one existing need for a TXT record
and that is SPF and
Alessandro Vesely wrote:
Correct. And the way that it fails to verify is h=from:from.
The only way that DKIM can consistently account for this exploit is by
amending section 5.5 Recommended Signature Content, and spell what
fields MUST/SHOULD be duplicated in the h= tag.
-0.5.
This is
Barry Leiba wrote:
On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote:
At 17:31 13-10-10, Hector Santos wrote:
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those with currently one
help adoptions without pains.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Barry Leiba wrote:
On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote:
At 17:31 13-10-10, Hector Santos wrote:
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those with currently one
.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
technical marketing of DKIM for
our customers. It provides a payoff for customers to support DKIM
and to upgrade their software to further harden it.
A win win for all.
Thanks Jim for stepping in and providing excellent text I hope
everyone can compromise and agree with.
--
Hector Santos, CTO
http
, especially with key management. We decided
not to deal with DomainKeys. We don't add it or verify it.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
to it will work.
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, the consensus was that only the first address in the
potetial list of from addresses in the single 5322.From header was the
only important author domain for POLICY considerations.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Mark Delany wrote:
Murray wrote:
My
are canonicalized for input to the
hash function, this would prevent additional fields from being added,
after signing, as this would render the signature invalid.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE
a model based
on this:
CHECK DKIM PASS -- ACCEPT
CHECK RFC5322 BAD -- REJECT
BREAK
RESIGN
DISTRIBUTE
To this:
CHECK RFC5322 BAD -- REJECT
CHECK DKIM PASS -- ACCEPT
BREAK
RESIGN
DISTRIBUTE
--
Hector
Ian Eiloart wrote:
Hector Santos hsan...@isdg.net wrote:
DKIM signed Double From Accepted, Resigned by mipassoc.org
Yes, we saw that.
No Signature, Double From --- Trapped/rejected by mipassoc.org
Really? You tested this? I assumed the message was accepted because
The next post with the example DKIM bypass exemplifies the point that
it is about DKIM fitting into the system, not the other way around.
The current text tries to too hard to pass the buck on other systems
when in fact, hate to say it, its about DKIM faults not anyone else.
This is especially
messages, but also bypassing
existing RFC 5322 checking.
Is this not important?
It clearly shows that DKIM needs to check its own DKIM requirements
and not rely on other layer.
Verification is not even mentioned in this new section.
Why not?
--
Hector Santos, CTO
http://www.santronics.com
http
. With DKIM, there is a loophole. Go figure.
Lets hope this DKIM exploit does not become common place and surprises
a bunch of layman operators. At the point, you can say you were aware
about it.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
John R. Levine wrote:
So here's a 0th cut at a list of headers where we should recommend
N+1 entries in the h=
rfc 5322
From
Sender
Reply-To (maybe not, since often smashed by mailing lists)
To
Cc(not Bcc even though it's 0/1)
Message-ID
Subject
how the 5322.Mime-Version header can be exploited.
Anyway, never mind.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Michael Thomas wrote:
On 10/07/2010 05:01 PM, John R. Levine wrote:
Nobody has signed a non-compliant message, so while there is nothing wrong
with Mike's advice, it completely misses the point.
You're right, it does miss the point. What I'm trying to get my
head around is whether this is
Wietse Venema wrote:
With this signer-side configuration solution, the verifier can
detect attempts to spoof any header that was covered by the DKIM
signature (spoof as in add a forged header, and hope that naive
programs will use the forged header instead of the authentic one).
So the
idea is good, but we don't know if most other DKIM
application implementations offer this. I believe Levine is correct
on this point that most implementations may not be this flexible.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
solved a 25+ year old problem.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
and my MUA (ThunderBird) somehow used the wrong From:
address with the text I was writing. My Apology to Jeff.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http
bar. In that vain this
multiple 5322.From issue is directly related to a DKIM purpose to
secure it.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org
.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
and I am not smart enough to
determine what real hackers can imagine to come up with.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
Charles Lindsey wrote:
On Mon, 04 Oct 2010 23:24:11 +0100, President Obama ob...@whitehouse.gov
wrote:
THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE
Interestingly, my MUA (Opera) displayed both of those From headers, But I
can quite well understand that many other MUAs
?
+1. This is where I thought it would go.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Ian Eiloart wrote:
-1
It is extremely relevant.
The data is there. The numbers can be calculated from the sample size
(~500k) and the proportions. They're nowhere near the numbers
(Originator signatures: 1.2 billion Third-party signatures: 184
million) that you quoted in another
Julian Mehnle wrote:
Hector Santos wrote:
It has been observed by implementations that is it possible to replay
a message with a 2nd 5322.From header at the top which wouldn't break
the DKIM signature validity, but would often be displayed by MUAs to
display the new 5322.From display rather
Ian Eiloart wrote:
--On 4 October 2010 18:24:11 -0400 Hector Santos hsan...@isdg.net wrote:
It has been observed by implementations that is it possible to replay
a message with a 2nd 5322.From header at the top which wouldn't break
the DKIM signature validity, but would often
Julian Mehnle wrote:
Hector Santos wrote:
Julian Mehnle wrote:
The trick is to list From twice in h=. This ensures more From headers
cannot be added without breaking the signature.
Julian, this was explored and it does not matter. You can add N
number of h=from: and N+1 is all
the buck to other layers
of email.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
[1] http://tools.ietf.org/html/rfc4686
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
shows the same
thing which the online gmail MUA will have an indicator:
signed by: some signer domain
but will it display the injected spoofed unbounded 5322.From?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Hector Santos wrote:
I would not be surprised if testing this with gmail.com shows the same
thing which the online gmail MUA will have an indicator:
signed by: some signer domain
but will it display the injected spoofed unbounded 5322.From?
For the records, from my gmail testing
Julian Mehnle wrote:
Hector Santos wrote:
Right. Does this add signer reputation weight for the injected
5322.From?
Probably not.
How do you know what the heuristic systems are doing?
AFAICT mipassoc.org doesn't verify DKIM sigs on list
messages,
it does. It verifies, adds
Stephen Farrell wrote:
On 05/10/10 23:54, Julian Mehnle wrote:
Recommending that one more From be added to h= (and hashed)
than From headers are initially placed in the message should be enough.
There is no need to change the semantics of the spec.
Assuming that recommending above maps
:
Organization:
X-Mailer:
What logic is there to this?
Of course, the signature was invalid.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
Sonneveld, Rolf wrote:
On 04-10-10, *Hector Santos *hsan...@isdg.net wrote:
I am wondering or under what scenario would a DSN (bounce) agent keep
the original signature in its bounce notification 5322 headers?
It was a legitimate bounce for a non-delivery address.� But it kept
several
I am seeing this because we are signing mail now and
I'm seeing the new invalid signature logging with these type of bounces.
--
HLS
Hector Santos wrote:
Sonneveld, Rolf wrote:
On 04-10-10, *Hector Santos *hsan...@isdg.net wrote:
I am wondering or under what scenario would a DSN (bounce
the
domain found in the From: header field. The remainder, therefore,
were third-party signatures.
Originator signatures: 1.2 billion
Third-party signatures: 184 million
Unbelievable!
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Barry Leiba wrote:
Thus begins working group last call on the DKIM implementation and
interoperability report, draft-ietf-dkim-implementation-report-02:
http://tools.ietf.org/html/draft-ietf-dkim-implementation-report
The working group last call will run through Friday, 22 October, 2010.
. This will mitigate any
replay that prepends a new 5322.From header to a DKIM signature
valid message. Some MUAs have should to display only the first
5322.From header found.
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list
901 - 1000 of 2143 matches
Mail list logo
