r acceptability.
Please note that I changed the focus in the above paragraph to
"desired" mail instead of "undesired" mail.
Regards,
-sm
___
ietf-dkim mailing list
ietf-dkim@mipassoc.org
http://mipassoc.org/mailman/listinfo/ietf-dkim
At 10:31 12-08-2005, Hector Santos wrote:
This is your standard benign Mailing List server adding footers etc,
breaking the integrity of any original signing.
You mean like this one? :-)
Regards,
-sm
___
ietf-dkim mailing list
ietf-dkim
of "joe job". This forgery is carried out mainly to
damage the reputation of a domain. Spam is sent using the
Return-path and RFC2822.From of the domain.
Regards,
-sm
___
ietf-dkim mailing list
ietf-dkim@mipassoc.org
http://mipassoc.org/mailman/listinfo/ietf-dkim
And they don't want to be bothered with "RFC2822.From".
Regards,
-sm
___
ietf-dkim mailing list
ietf-dkim@mipassoc.org
http://mipassoc.org/mailman/listinfo/ietf-dkim
nt, the receiving end use heuristic rules to determine the
origin of the email and assess it. DKIM provides a means to identify
the origin without undue constraints on the path.
Regards,
-sm
___
ietf-dkim mailing list
ietf-dkim@mipassoc.org
http://mipa
st end-users cannot understand the difference.
Most end-users do not subscribe to mailing lists and if they do, they
may sometimes report mail received from the list as spam. :) Those
who do subscribe can only understand that the mail is from a mailing
list if
DKIM as an anti-spam measure,
and only refer to it within the context of the problem it actually
addresses: email identity forgery. Of course, people will make
inferences that DKIM is an anti-spam measure, but DKIM documents
should not even mention spam.
I agree.
Regards
age.
The main benefit of DKIM is that a validating agent can know who is
responsible for the message. This is more reliable than email source
identification has ever been before. Furthermore, DKIM does not put
any constraints on the delivery path.
Re
Your definition is better as it avoids the confusion with roles such
as sender or author.
Regards,
-sm
___
ietf-dkim mailing list
<http://dkim.org>;
x27;t like it.
Yes, that was what I was trying to say. Douglas provided a better definition.
The main benefit of DKIM is that a validating agent can know who is
taking responsibility for the message.
That's clearer.
Regards,
-sm
___
iet
accountable, some people may infer it. Undesirable messages will
affect the reputation of the signing domain.
Regards,
-sm
___
ietf-dkim mailing list
<http://dkim.org>;
mes down to the receiver's end
making the final decision. DKIM cannot stop people from "using our domain".
Regards,
-sm
___
ietf-dkim mailing list
http://dkim.org
implementation guidelines can help. If we want to
prevent ambiguity and variability, it will come at the cost of
restrictions on how email is used. If a domain elects not to have a
SSP record, we can assume that the owner does not want DKIM.
Regards,
-sm
-Results header comes in.
Regards,
-sm
___
ietf-dkim mailing list
http://dkim.org
e value to your score. This would be domain
based. One of the advantages of a domain-based approach is that you
don't have to track IP address changes. Your customers might prefer
to have their own list instead of using a lookup service operated by
a third p
played
in any context that might be construed by the end user as having been
signed."
It could be extended further:
The "From:" header should not be signed if it contains more than one
sending address.
Regards,
-sm
___
ietf-dkim mailing list
http://dkim.org
e "c=relaxed/relaxed".
Regards,
-sm
___
ietf-dkim mailing list
http://dkim.org
t; tag should be restricted to email addresses within the SSP
domain being queried. The host part of the email address should be
constrained to be within the SSP domain. You can then use email
addresses such as [EMAIL PROTECTED] or [EMAIL PROTECTED]
Regards,
-sm
___
s the scope for a denial of service.
The "r=" tag is not for reporting abuse. I used "[EMAIL PROTECTED]"
as an example only.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html
t; tag is about the signing policy for the
domain. The alternatives are:
1. Restrict the tag to localpart
2. Restrict the tag to hosts within the domain
3. Remove the tag.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html
n being queried. The host part of the email address should be
constrained to be within the SSP domain."
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ess within their domain. For domains where use of their
Are you talking about reporting DKIM signatures that cannot be
verified? If so, I don't see how you can trust the report vector
acquired from the signing-domain.
Regards,
-sm
___
NOTE
costly.
The validator decides whether to send reports or not. Note that I am
not suggesting that automated reports should be sent or that this tag
should be used for them.
Regards,
-sm
___
NOTE WELL: This list operates according to
http
ch was
to remove the tag.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
the content into the Internet Mail service.
As we move down the distribution chain, we find that the publisher
may be identified as the responsible party as he/she can, to some
degree, do content "approval" and identify the author.
Regards,
-sm
__
or to raise a concern. Please clarify.
I agree with your definition from Publisher downwards. My point in
regards to the author definition is that if we cannot determine the
identity, then we cannot establish responsibility.
Regards,
-sm
___
NOT
accountability...
OK. Does my above discussion clarify that the language is not meant
'author responsibility' does not require knowing know who the author is?
Yes, it clarifies it.
Regards,
-sm
___
NOTE WELL: This list operates accordin
Hello,
At 10:05 05-04-2006, [EMAIL PROTECTED] wrote:
Yes, the case indicates importance, much like bold/italic or underline,
not meaning
I believe http://www.ietf.org/rfc/rfc2119.txt sums it.
Regards,
-sm
___
NOTE WELL: This list operates
limited to alphabetic characters, digits and hyphen.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
At 12:01 15-07-2006, Stephen Farrell wrote:
The question: is it better for this document to be published as an
historic RFC "now" or at the same time as the standards track DKIM
base RFC is published? (Where all timings here are modulo the RFC
same time.
Re
02005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org
say: +1
If you want to keep that requirement say: -1
+1, eliminate that requirement.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
mailing list or a forwarder.
DKIM operates entirely on the content of the message (RFC 4686
Section 1.1). Your requirement goes against that. Maybe you could
use "revocation identifiers" as described in the Chosen Message
Replay scenario.
Re
odate mailing lists and forwarders.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
trusted,
mail from them should not be DKIM-signed.
Can you provide a specific example where DKIM signed mail from
[EMAIL PROTECTED] to me is protected from abuse?
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org
ublic
access to their service, the bad-actor could re-enroll and continue
this behavior non-stop. Replay abuse mitigation will become
Your proposal does not prevent the bad actor from re-enrolling.
Regards,
-sm
___
NOTE WELL: This list operates accordi
At 14:53 29-05-2007, Douglas Otis wrote:
It's an administrative burden. We can always tell which path a
mail may take.
You mean we can't always tell? Yes, some notification to customers
Yes, I meant "cannot". :-)
Regards,
-sm
_
the gTLD and ccTLD
or there must be a way to extract this information.
It's not as simple as it sounds. It may take a long time to get that
information out of all the gTLDs and ccTLDs. I doubt they'll even
agree to a registry for that. It's not a technical problem.
This message has been forwarded to the DKIM list.
Date: Thu, 27 Sep 2007 16:36:04 -0400
From: John C Klensin <[EMAIL PROTECTED]>
(someone will probably need to forward this to the DKIM list;
I'm not subscribed to it)
--On Thursday, 27 September, 2007 12:12 -0700 Douglas Otis
<[EMAIL PROTECTED]
Hi Hector,
At 12:32 02-11-2007, Hector Santos wrote:
I am wondering if there is an open source C/C++ library that is
current with the latest DKIM/SSP technical specifications that I can
analyze and work with to update our own library.
See dkim-milter.
Regards,
-sm
r all, its only a test.
"t=y" means that the domain is testing DKIM. Some domains can run a
test in a few days and reach a conclusion while others may require
in-depth testing. The sender do care about the disposition of the
message, hence the test.
Regards,
-sm
_
operability testing while
others may only be noticeable in a production environment. It makes
sense for a domain to remove that attribute only when they are
comfortable that their implementation is working correctly.
Regards,
-sm
___
NOTE WELL: This li
At 07:05 09-11-2007, Eric Allman wrote:
explicitly non-disclosure. However, it's not hard to find
information about ARF (Abuse Reporting Format).
http://www.ietf.org/internet-drafts/draft-shafranovich-feedback-report-03.txt
Regards
recipient."
as the organization, an ISP for example, is not responsible for the
"content" of the message. The signer is merely offering a means for
the original or intermediate transmission to be validated.
The above comment applies to draft-ietf-dkim-d
le case in one of the
messaging RFCs (can't remember which now).
RFC 2822, Appendix A.1.
The author's domain can be different from the sender's domain.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
such features. That's
not a reason to question its legitimacy. We might as well move RFC
2369 to obsolete status because most people don't know about it.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org
ty if the From: shows an example.com author?
See RFC 5016, Section 3.2 (Problem Scenario 2: Illegitimate Domain Name Use).
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ase?
The From: field is not optional (2822). If there isn't an author
address, there isn't a domain on which the implementation can do a SSP lookup.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, policy)
groups, although the only service type in the registry now is "email".
DKIM is also referenced in SIP. To make room for a service type, you
could have a record such as email._ssp._domainkey.example.com.
Regards,
-sm
___
NOTE WELL:
t, submission via
a path without access to a signing key, or other reason, the
domain encourages the recipient(s) to discard it instead of
sending a "bounce".
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
mail by mandating a
>DKIM/ASP design of delaying the payload analysis to POST SMTP.
If you mean DKIM/ASP verification, that can be done during the SMTP session.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ck, the receiver might as well drop all mail from that domain.
>The receiver domain is likely to choose to balance the benefit from
>listening to discardable assertions and the increase in support calls
>that might result from any particular domains discardable assertion.
Yes.
Regards,
picious content". The same intent may
> > already be included in 4.2 "s ... signed and Suspicious".
>
>Not a bad idea. Any comments from others?
This draft is for reporting DKIM verification issues. Wouldn't the
above change the purpose of the draft?
Regards,
At 17:16 17-03-2008, Mark Delany wrote:
>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.
http://www.rfc-editor.org/how_to_report.html
Regards,
-sm
__
P - Sender Signing Practices
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
d how computers work you MUST NOT try
>to create security programs for 3rd party use.
Although the proposed text a good recommendation, it's not the type
of wording for a RFC.
Regards,
-sm
___
NOTE WELL: This list operates according to
http:/
? I'm ignoring any ADSP considerations.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ure to protect such domains.
We have to extrapolate from there and cover domains (i.e.
sub-domains) that don't exist if they can be used to circumvent ADSP.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
he sender was an ISP
as host1.adsl.example.net is not treated the same as example.com then.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Domain (Section
3.1), is Section 4.2.2 applicable?
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
e message is
already known to be compliant with any possible ASP for that
domain.
I read that as meaning that as the ASP (ADSP) lookup is not done
then. I'm not saying that it should not be done. :-)
Regards,
-sm
___
NOTE WELL: T
an access those records.
I suggest adding "valid".
The assessment applies for messages that do not contain a valid
DKIM signature for
the domain used in the author's address. It defines a record that
can advertise
whether outgoing mail for the domain
whatever rules the Working Group
agrees upon.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
e, it's better to do a
sanity check on the headers before verifying the signature and flag
non-conformant messages.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ude headers that are not
present. There is an informative explanation in the RFC about that.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
;
RFCs are generally published. That word could be dropped from the sentence.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
r high level
questions about deployment and operations. If there is too much
"noise" because of user level questions, people may stop paying
attention to the list and it won't fulfill its purpose anymore.
Regards,
-sm
___
NOTE
fr).
>
>I do not think it is legitimate but I may miss something. Any
>reasonable use of such a record?
Neither DomainKeys nor DKIM use such a record. You are getting that
A record for these domains as there is a wildcard DNS record.
Regards,
-sm
_
using a non-null value.
As RFC 4870 is published as Historic, it is better to leave it as it
is. If the mail provider does the change, the problem will go away quietly.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
sages which may be
viewed as spam. The signer may set a signature expiration to limit
replay attacks.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
gets sorted), that incorporates
>all agreed errata to date? If not, then what?
That may be the best route.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
key granularity (g= in Section 3.6.1) when "d=" is considered as
the "stronger" identity.
>Errata aren't allowed to fix something by changing it?
Based on the first paragraph that I quoted and the current
discussion, the answer in this case is no.
Regards,
-sm
_
header field Local-part can be authorized.
I understand that the identity from i= is opaque and it is not
required to match
the identity in any message header fields. If the identity is
stable, a verifier could implement a policy to identify that
"source". This can b
f the RFC 2119 keyword. I don't
see how to implement a requirement based on the additional knowledge
as it may fall under local policy unless there is a mechanism for the
sender and receiver to exchange that information.
Regards,
-sm
___
NO
bis goes through
>the process.
The WG could also consider doing the above once there is agreement
about the changes.
Regards,
-sm
1. http://mipassoc.org/pipermail/ietf-dkim/2009q1/010877.html
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
in part opaque too. The corrected text in the
Errata changes the introduction to "permitting a person, role or
organization that owns the signing domain to claim
responsibility". I don't see how anyone can claim responsibility
when we cannot identify the signing domain.
Regards,
can use
it as an identifier for you. I do not need to
know why you are using that name. The argument
against i= seems to be that it should not be used
as we don't know why that name is being used.
The WG could, as part of some future work,
consider obsoleting the "i=&quo
eployment problems. DKIM is still young by most standards.
If we can't agree on what RFC 4871 meant, then we will face the same
situation with RFC 4871bis.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
the address is a subdomain.
>By far the largest stream of DKIM signed mail is from gmail which
>doesn't use i=.
There is a problem with their interpretation of a DKIM signed mail
when the i= is set.
Regards,
-sm
___
NOTE WELL: This list
a document about deployment.
J.D. suggested leaving i= opaque and see what operators (on both ends
of the transaction) do with it. That could be discussed in a
document about deployment.
Given the scope of Dave's proposal, I'm still not comfortable with it
as an erratum. I choose Eliot's proposal (d).
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
he "i=" value and other
identities is not well established, nor is its vulnerability
to subversion by an attacker. Hence reliance on the use of
these options should be strictly limited. In particular, it
is not at all clear to what extent
the job of a specification, not a usage
>document. How does Jim's draft help leave i= as opaque?
I suggested some text for the errata. The text leaves the Local-part
of the "i=" value as opaque.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Standards Track or even asking for publication?
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
cerns about that draft, it is better to have them voiced out now
so that the WG can decide where ADSP stands.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
At 15:24 11-03-2009, HLS wrote:
>This domain has no content, totally blind. I would not trust this
>dkimcore . org until they reveal themselves.
The person who wrote that document revealed himself/herself. :-)
Regards,
-sm
___
NOTE WELL: Thi
t as a substitute for the IETF community.
There isn't a formal definition of "IETF rough consensus". From the Tao:
"a simple version is that it means that strongly held objections
must be debated
until most people are satisfied that thes
I note that SSP and
the Overview document were set for WGLC in November 2007 according to
the charter. The Deployment document is still work in progress. It
would be better for the DKIM WG to meet its goals before starting a
discussion about Draft Standard.
Regards,
-sm
_
King's myself).
In my opinion, people will take whatever input they view as useful
for an assessment. There is nothing we can do about that except to
say "don't do it". John Levine made a good point about interoperability.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
matter whether
>the VBR-Info header is signed, because the recipient isn't going to
>believe anything it says without checking first.
That's one way to use DKIM. This brings us back to the question of
whether we should constrain the specification to do that only and
leave any ot
agree with some parts of John Levine's
message. If we could iron out points of agreement and disagreement,
it might help in moving forward.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
is a ClockDrift setting to deal with that. People generally do
not notice this problem when they debug verification failures.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
It
also contains a list of header fields that should not be signed. The
Return-Path header field is listed in there.
If you believe this is a real-world concern that should be addressed,
you could specify that the Return-Path header field must not be
included in the signature.
Regards,
This header should be removed from section 5.5. Recommended
>Signature Content (The following header fields SHOULD be included in the
>signature ...).
Won't the change in content-transfer-encoding (not the header field)
performed by an MTA affect the body part and by extension break t
ng it free-run
>is at least unrespectful and confusing to recipients or senders,
>or can cause mail misclassification/blocking at worst.
The verifying host should also be running NTP.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
lose this issue.
The "update" document affects the ADSP, Overview and Deployment
documents. Can the DKIM Chair state in which order the documents
will be processed?
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
he WG wants to be precise, I'm fine
with that. The interpretation of domain name here is within the
context of DNS. For those of you who don't understand what that
means, please talk with the DNS folks. They are highly skilled in
the art of frustrating application designers when that q
sions built upon DKIM.
Regards,
-sm
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
s only basic
> domain name semantics; any possible owner-specific semantics is
> outside the scope of DKIM.
I'm okay with this as long as any update of RFC 4781 fixes any text
that is affected by the new changes. I'm not quoting any text as
it's better to get the current
elivered to this module as well as to a
more general message evaluation filtering engine. However
this additional
activity is outside the scope of the DKIM signature specification.
If you want to deliver non-DKIM values, then it does not sound right
to have DKIM in the name. If th
. When you say
that "ADSP incompatible with valid DKIM usage ...", people will
register the word "incompatibility" and view valid DKIM usage as
mostly about third party signatures.
I find it difficult to comment on this point alone as the issue
1 - 100 of 179 matches
Mail list logo
