On Fri, 8 Jun 2007, Hector Santos wrote:
Charles Lindsey wrote:
Why not?
So you are expecting Nominet (the managers of the uk TLD, and of co.uk,
org.uk, net.uk, etc under it) to administer the '_ssp.uk' domain on behalf
of Demon and all the 9 other *.co.uk domains that have been
On Thu, 7 Jun 2007, Hector Santos wrote:
Example #1:
A company may want a I ALWAYS SIGN ALL DOMAINS, with NEVER exceptions after
the b.c.d.foo.com subdomains:
*._SSP 0 TXT policy=ALWAYS
*.b.c.d._SSP 0 TXT policy=NEVER
Example #2:
A company may want a global
On Sat, 2 Jun 2007, Steve Atkins wrote:
The problem is that you've just spec'ed SSP to use a protocol that
is not DNS. It's fairly similar to DNS, but it's not DNS. I can't
imagine the IESG accepting that in a standards track document.
No, it's perfectly compliant DNS. Really, it is.
It's
On Wed, 30 May 2007, Jim Fenton wrote:
What we had hoped to do in the next revision of the allman-ssp draft was to
unify it as much as possible with Phill Hallam-Baker's draft. I opened three
new issues on April 16 that I think need to be resolved in order to do that.
(1) Use of XPTR
On Wed, 30 May 2007, Douglas Otis wrote:
On May 30, 2007, at 4:54 PM, william(at)elan.net wrote:
(3) Upward query vs. wildcard publication. 27 messages in discussion
from 15 people. Most of the discussion was a rehash of the idea of
associating semantics with DNS zone-cuts, which we had
Diff please.
On Fri, 18 May 2007, Dave Crocker wrote:
Howdy,
We've put together a new version of the spamops document (Email
Submission:
Access and Accountability) that was developed a couple of years ago. We
are
expecting it to be issued as an IETF Best Current Practices.
Take a look
On Thu, 4 Jan 2007, John L wrote:
Can you describe the algorithm to distinguish the cases where the original
value is fine from the cases where it's not?
You took one line without additional context where I gave an example of
users who have processing script to find mail lists based on
On Tue, 2 Jan 2007, John Levine wrote:
I would support some gentler language that permits use of z= in
verification, with particular attention paid to ensuring that a new
security vulnerability is not introduced.
My recollection is that we had no idea what the security
vulnerabilities would
On Wed, 3 Jan 2007, John R Levine wrote:
No. What you'd want to do is to rename modified header field into some
sort of trace data and copy the original data in its place. Displaying
modification would then be up to the MUA which could display small
icon allowing user to see what the
On Wed, 29 Nov 2006, Charles Lindsey wrote:
On Tue, 28 Nov 2006 15:42:11 -, Scott Kitterman [EMAIL PROTECTED]
wrote:
2822.From is the only identity that is reliably displayed to the end user.
I utterly fail to see why what is displayed to the user is of the least
relevance.
On Fri, 24 Nov 2006, Jim Fenton wrote:
william(at)elan.net wrote:
Neither one the designers of DK[IM] are particularly interested in dealing
with as is evident in previous discussions in regards to 3rd-party policy
considerations or 3rd-party signers.
Your use of neither one
On Fri, 24 Nov 2006, Charles Lindsey wrote:
If posting via the RFC NEWSREADER, the NNTP Server will transform the NNTP
article to EMAIL.
Yes, that is the interesting case. A news2email gateway is, from the POV of
this WG, just another agent for generating emails (and as such it is on topic
keep 'designation'
[note: I don't like that naming system, but that is not worth debate]
On Fri, 29 Sep 2006, Stephen Farrell wrote:
So - on the jabber chat we almost established a rough consensus
not to include designation at this point.
If no-one else speaks up either way, I reckon that
On Sat, 9 Sep 2006, Dave Crocker wrote:
The list discussion seems to be spending an awful lot of time on issues that
are theoretical, poorly understand, and lacking in a clear community
consensus that we need a solution.
How is this productive?
Your own message is perfect example of
On Wed, 6 Sep 2006, Jim Fenton wrote:
The tree-walking issue (separate from the user-level SSP) issue has
concerned me too. The allman-dkim-ssp-02 draft has it down to 2 queries
-- much improved from the previous revision, in part because of the use
of a separate RR.
Are you sure there is a
On Wed, 6 Sep 2006, Hallam-Baker, Phillip wrote:
If we do have per user policy I think that it needs to be defined in
such a way that it is clear that it is an extension. So for example if
DKIM is the tag describing the domain based DKIM and USER is the per
user version of the policy
On Wed, 6 Sep 2006, Jim Fenton wrote:
The aspect of user-level SSP that concerns me equally is the transaction
load. When user-level SSP is turned on, the verifier MUST query for a
user-level record in addition to the domain-level record. User-level
queries are not as effectively cached,
On Wed, 30 Aug 2006, Wietse Venema wrote:
william(at)elan.net:
On Wed, 30 Aug 2006, Dave Crocker wrote:
John Levine wrote:
If I understand your position, you are positing that someone will pay
between $20 and $50/mo for Internet access, probably some extra amount
per month for a DKIM
On Thu, 31 Aug 2006, Wietse Venema wrote:
This thread was about the delegation of the DKIM signing operation
including the delegation of DKIM public key information. Whatever
delegation methods are used (DNS or other), they would have to be
built into DKIM verifiers.
My apologies. With so
On Wed, 30 Aug 2006, Dave Crocker wrote:
John Levine wrote:
If I understand your position, you are positing that someone will pay
between $20 and $50/mo for Internet access, probably some extra amount
per month for a DKIM-capable mail service, but they use a crummy DNS
service where they
On Tue, 29 Aug 2006, Steve Atkins wrote:
What am I missing here?
Taking responsibility for email is not the same as protecting From
address from unauthorized use. I may want to have someremailer.com
take responsibility for remailing the message that passes through them
where as when I send
I've proposed before that in case of large number of domains SPF-like
macro expansion be allowed in place of actual domain.
On Fri, 25 Aug 2006, Jim Fenton wrote:
[This is the first of a two messages outlining my concerns about SSP
Designated Signing Domains. I'll break each category of
On Fri, 25 Aug 2006, Jim Fenton wrote:
While we aren't defining reputation or accreditation services in this
working group, it has been widely suggested that such services would use
the d= domain on the signature as the lookup key for retrieving
reputation or accreditation information.
Not
On Wed, 9 Aug 2006, Hector Santos wrote:
I was thinking about this and wasn't sure if it was worth bringing up. I
mean, in DSAP we have failure-handling statements, but I can go either way.
But let me throw out the idea of the domain wishing to express a disclaimer
that is something
On Wed, 9 Aug 2006, Scott Kitterman wrote:
On Wednesday 09 August 2006 21:29, Hector Santos wrote:
It was my contention that the SSP should ALWAYS be done against the
2822.From regardless of how DKIM-Signature domain was bounded.
+1
Would you remind me how this would work with multiple
On Thu, 10 Aug 2006, Hector Santos wrote:
- Original Message -
From: william(at)elan.net [EMAIL PROTECTED]
To: Scott Kitterman [EMAIL PROTECTED]
On Wed, 9 Aug 2006, Scott Kitterman wrote:
On Wednesday 09 August 2006 21:29, Hector Santos wrote:
It was my contention that the SSP
Most legitimate Resent cases are such where last sender (person listed
in Resent-From) would very likely be be on the personal whitelist of
the recipient because of extensive prior communication.
BTW - this means that absolute/strict policy may not be absolute in
practice where the filter
On Thu, 10 Aug 2006, Hector Santos wrote:
- Original Message -
From: william(at)elan.net [EMAIL PROTECTED]
To: Hector Santos [EMAIL PROTECTED]
Cc: Scott Kitterman [EMAIL PROTECTED]; ietf-
What's wrong with checking each one? I mean, why
allow for a loophole?
Wasn't one
That this thread is being discussed brings up a requirement that policy
record syntax should be capable of supporting multiple identities.
A subquestion of that is if policy record identity should or should
not be part of the query selection process (i.e. _from._policy if DNS).
That BTW
On Tue, 8 Aug 2006, J.D. Falk wrote:
On 2006-08-08 11:43, Scott Kitterman wrote:
Sounds like false hope to me; as a big receiver, I can't imagine that
I'd ever want to blindly trust assertions made by an unknown sender.
As both you and John L point out, this is a big issue. That's why I
On Sun, 6 Aug 2006, Michael Thomas 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 also support strong policies:
I
On Sun, 6 Aug 2006 [EMAIL PROTECTED] wrote:
Why not take an AIN approach? An SSP query to determine how to route the
message, with additional signatures, without and directly?
AIN?
--
William Leibzon
Elan Networks
[EMAIL PROTECTED]
___
NOTE WELL:
On Sat, 5 Aug 2006, Hector Santos wrote:
Agreed. That's what I've been thinking all along.
In other words, your 3rd party dnsbl-like DAC business venture with some
highly exploitable VBR protocol, with $10,000, $5000 entry feeds, with
absolutely no plans for SSP, is the right solution for
On Sat, 5 Aug 2006, John L wrote:
In no way does accreditation=DKIM
But policy records are in a way. Lets look at it in general -
policy record is just a statement of what sender believes to
be true about their email system setup and how receiver can
use the email..
Accreditation is
On Tue, 1 Aug 2006, Stephen Farrell wrote:
Evening Hector,
Hector Santos wrote:
So this policy basically becomes an emulation of the direct 1 to 1 mail
transaction no change expectation. It would not be used where there
might
be an expectation of mailing list servers in involved.
Now
On Fri, 4 Aug 2006, Damon wrote:
4.7. DSAP Tag: t=y
The t=y tag is optional. If defined, the domain is currently testing
DKIM. Verifiers SHOULD NOT treat testers any different from
production mode signers. It SHOULD NOT be used as a way to bypass a
failed signature classification
On Fri, 4 Aug 2006, william(at)elan.net wrote:
That makes no sense at all to me and is a straight
consequence of the addition of a signature having a
negative effect.
I was on the linux conference recently in the security-area where
presenter said SELinux extensions would always make
On Fri, 4 Aug 2006, Damon wrote:
I want to add a little more...
It would also be ok if there was an alternative that was useful... and
will just refer to my previous posts as to why I thing I SIGN SOME's
value is not worth the expense.
Before you said you want I sign some if it comes from
Some people unfortunetly never introduced tag (present for example in IIM)
specifying which server actually adds DKIM signature. This makes it
impossible to extend in the way you proposed as receiver would not know
server/network responsible for adding particular signature when email
is
lookups.
Come on William.. how many good arguments do I need to convince you ;)
Regards,
Damon
On 8/2/06, william(at)elan.net [EMAIL PROTECTED] wrote:
Some people unfortunetly never introduced tag (present for example in
IIM)
specifying which server actually adds DKIM signature. This makes
On Fri, 28 Jul 2006, Jim Fenton wrote:
william(at)elan.net wrote:
On Fri, 28 Jul 2006, Stephen Farrell wrote:
A similar question to the previous one.
Current proposals involve searching for SSP stuff based on
the domain part of an unsigned message's RFC2822.From element.
Are there any
On Mon, 31 Jul 2006, John L wrote:
The statement that I sign only my own mail makes perfect sense.
If I have a message with your valid 3rd party signature, meaning that you've
published the key, and your SSP says you sign only your own mail, which do I
believe? Why or why not?
You
On Mon, 31 Jul 2006, wayne wrote:
In [EMAIL PROTECTED] Mark Delany [EMAIL PROTECTED] writes:
On Mon, Jul 31, 2006 at 09:59:19AM -0400, [EMAIL PROTECTED] allegedly wrote:
The statement that I sign only my own mail makes perfect sense.
If I have a message with your valid 3rd party
On Mon, 31 Jul 2006, Dave Crocker wrote:
Author:
Creates message content
Mailing-List: Creates message content, based on existing messages
I have a problem with above line. In my view mail list can not be
considered an author of the message.
Recipient: End-user who may read the
On Fri, 28 Jul 2006, Stephen Farrell wrote:
A similar question to the previous one.
Current proposals involve searching for SSP stuff based on
the domain part of an unsigned message's RFC2822.From element.
Are there any other requirements there or is that the only
basis on which we need to
On Fri, 28 Jul 2006, Stephen Farrell wrote:
Folks,
We all (or almost all) seem to be assuming that the DNS is the
place to put SSP stuff.
DNS is not the right place to put public keys either - its been
shown here many that it makes DNS systems vulnerable to attack when
you put such large
On Fri, 28 Jul 2006, Hector Santos wrote:
- Original Message -
From: Stephen Farrell [EMAIL PROTECTED]
Anyway I guess this is just another argument to require support for
inclusion of some kind of allowed-signer list in SSP statements, and
maybe also for a requirement that the SSP
On Fri, 28 Jul 2006, Hector Santos wrote:
From: william(at)elan.net [EMAIL PROTECTED]
That 3pl may have been misspelled in the table listing possible tags
as dl. Please check.
You reviewed an earlier draft-01 which had it as dl. I changed it to 3PL,
made other reviewer changes/input
On Wed, 26 Jul 2006, Scott Kitterman wrote:
On Wednesday 26 July 2006 15:26, Steve Atkins wrote:
MX 0 . seems to be the standard way of asserting that a domain
neither sends nor receives email.
It is a way that people do it. AFAIK, there is no standard that
describe that assertion.
On Mon, 5 Jun 2006 [EMAIL PROTECTED] wrote:
Well I hate to insist that signers SHOULD do anything but doesn't the
issue of multiple signatures belong in a mail list addendum rather than
base? If I am forwarding should I want to forward an unverifiable
signature over my verifiable one, how
On Thu, 1 Jun 2006, Douglas Otis wrote:
There should be a security consideration mentioning an unintended consequence
when a different entity controls sub-domains of a high level domain. This
could be viewed as an ICANN, ARIN, APNIC, LACNIC, AfricNIC, RIPE NCC,
Could you explain what the
On Fri, 26 May 2006, Paul Hoffman wrote:
At 6:08 PM -0700 5/26/06, Douglas Otis wrote:
... [EMAIL PROTECTED] d=co.uk
Currently this is permitted in the base draft which indicates the parent
domain is authoritative for sub-domains.
This is absurd. Under which scenario would a signer in
On Thu, 18 May 2006, John Levine wrote:
NEW:If there are
NEW:multiple query mechanisms listed, the choice of query mechanism
NEW:MUST NOT change the interpretation of the signature. An
NEW:implementation MUST use the recognized query mechanisms in the
NEW:order presented.
On Sun, 30 Apr 2006, Paul Hoffman wrote:
At 8:49 AM -0400 4/30/06, Tony Hansen wrote:
Paul Hoffman wrote:
It is up to the verifier to decide how much effort after the first
attempt it wants to do. The cost to the verifier is a doing multiple
hashes, not doing multiple signature
You can not avoid such ambiguities unless you can specifically reference
the copied data as part of signed header field listing. That is why I went
with copying to make new header field and referencing that in my design.
On Thu, 27 Apr 2006, Tony Hansen wrote:
I also read it the same way
On Fri, 28 Apr 2006, Eric Allman wrote:
The z= tag is only supposed to be used for diagnostic purposes, not for
computing the hash. Changing that would have major implications that we
would have to examine very carefully.
So if mail list changed Subject header field (and for purposes of
On Fri, 28 Apr 2006, Eric Allman wrote:
The z= tag is only supposed to be used for diagnostic purposes,
not for computing the hash. Changing that would have major
implications that we would have to examine very carefully.
So if mail list changed Subject header field (and for purposes of
On Wed, 19 Apr 2006, Jim Fenton wrote:
There is a *huge* difference between key and signature expiration.
Given that x= appears in a signature, the informative note should say
...indicate signature expiration. But, if we do that, we need to say
what it means for a signature to expire. We can
On Thu, 20 Apr 2006, Mark Delany wrote:
On Thu, Apr 20, 2006 at 10:21:56AM -0700, william(at)elan.net allegedly wrote:
BTW, the feature saying the message itself is valid up to certain date
could be quite useful. Many emails are written with expectations that
they would be read in 1-2 days
On Thu, 20 Apr 2006, william(at)elan.net wrote:
BTW, the feature saying the message itself is valid up to certain date
could be quite useful. Many emails are written with expectations that
they would be read in 1-2 days and if not done message content is no
longer of a significant use
On Wed, 12 Apr 2006, Lyndon Nerenberg wrote:
On Apr 12, 2006, at 10:24 PM, John L wrote:
My understanding of a DKIM signature is that it's the same idea as the clip
at the end of a political ad where the candidate says I'm Joe Blow and I
approved this message. The signature doesn't mean
Since fingerprints have specific meaning in cryptography, can you
change the name to something like Unique Signature ID (i.e. u
although personally I like us for URLs).
How you planning to make reference to specific header field by using
this tag? Are these going to be similar tricks to what I
On Tue, 11 Apr 2006, Mark Delany wrote:
So, color me slow. We know for sure that signing happened in the
past. What specific value do we place on how far in the past that
signing occurred? What code do I write to test that specific value and
what do you recommend that a verifier do with such
On Tue, 11 Apr 2006, Mark Delany wrote:
On Tue, Apr 11, 2006 at 06:26:43AM -0700, william(at)elan.net allegedly wrote:
On Tue, 11 Apr 2006, Mark Delany wrote:
So, color me slow. We know for sure that signing happened in the
past. What specific value do we place on how far in the past
On Fri, 7 Apr 2006, Michael Thomas wrote:
The alternative is to just put normative guidance in the document to the
effect that x= MUST be greater than t=+2weeks, and less than t=+2 months
or something, and that it SHOULD be set to t=+4 weeks.
I guess I worry a little about codifying an
On Mon, 27 Mar 2006, Hector Santos wrote:
- There is only a small deployment of SSP records at this point
- There are good reasons for going to a new RR
- Unlike key records, there's no way to advertise whether to do a TXT or
new RR query for SSP
it seems like there are good reasons to
On Tue, 28 Mar 2006, Tony Hansen wrote:
So it sounds like their database *will* support the additional RR
values, it's just that they don't make it easy to use them.
Until they get their standard interface fixed, it sounds like Microsoft
(or a 3rd party) could provide an alternative interface
On Fri, 24 Mar 2006, Arvel Hathcock wrote:
I believe this mailing list sends the same message (including the same
header fields) to everyone,
I don't understand because my copy has TO: [EMAIL PROTECTED] in the
headers. Why would the list send a message to you with my address in the TO:
On Thu, 23 Mar 2006, Mark Delany wrote:
On Tue, 21 Mar 2006, william(at)elan.net allegedly wrote:
Its nice to see you finally come around and adapting further META
signing structure
...
of course you will probably never admit where this is all coming
from ...
Of course we will. The idea
On Tue, 14 Mar 2006, Dave Crocker wrote:
Taking my own advice:
Mailing list software takes delivery of a message and posts a new message.
The new message might look almost exactly like the old one or it might look
massively different.
Massively different is overstatement of how mail lists
Some of those involved in this debate are missing that in many cases
email message may have multiple content parts are they may not
necessarily be from the same author or introduced into transport by the
same party. The terms author and originator should really be content
specific and not
On Tue, 28 Feb 2006, Hallam-Baker, Phillip wrote:
Just so you know the current cisco.com DKIM record results in
342bytes message data (do dig txt
nebraska._domainkey.cisco.com) and security of this key is
may not be sufficient and many will probably use 2k ones in
the future. The original
which will in any case be seeing a heavy load.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
william(at)elan.net
Sent: Monday, February 27, 2006 10:46 AM
To: ietf-dkim@mipassoc.org
Subject: [ietf-dkim] Threats Issue - Large DNS records make
servers
be
used for amplification (slightly worse amplification factor of 1:20).
The smart way to avoid this becoming an issue is to either use TCP or
to use UDP protocol with fixed and fairly small response packets.
-Original Message-
From: william(at)elan.net [mailto:[EMAIL PROTECTED]
Sent
On Wed, 22 Feb 2006, Hector Santos wrote:
Jon,
Is there any issue in regards to the idea of having a signer/validator
capability logic?
We can have a base defaults (SHA1, SHA-256) or whatever you experts deem
necessary. But in an advanced implementation, the validator can define its
Just note to start with that current SSP syntax is not really compatible
with SPF on the protocol level. It just uses some of the same symbols that
have special meaning in SPF, but the way they are used (policy=symbol) is
very different then spf where symbol is prefix for mechanisms. The
Obviously per your limited charter you'd consider this OT, but still FYI.
-- Forwarded message --
Date: Tue, 7 Feb 2006 17:25:38 -0800
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org, [EMAIL PROTECTED]
Cc: ietf-pkix@imc.org, rfc-editor@rfc-editor.org
Subject: RFC 4387
SSP is ability to indicate policy for email address, i.e. when you see
address in from you can check to find if emails from that address are
supposed to be signed. If you only check policy record when you see a
signature - this pretty much breaks the reason for having such policy
record in the
On Thu, 26 Jan 2006, Jim Fenton wrote:
william(at)elan.net wrote:
On Thu, 26 Jan 2006, Mark Delany wrote:
Right. So the question is, can a signature be constructed such that it
doesn't interact with SSP to infer a binding above and beyond I claim
it passed through me?
Make 'i' optional
On Thu, 26 Jan 2006, Mark Delany wrote:
Right. So the question is, can a signature be constructed such that it
doesn't interact with SSP to infer a binding above and beyond I claim
it passed through me?
Make 'i' optional.
My preference however is to have field in signature that specifies
On Tue, 24 Jan 2006, Jim Fenton wrote:
Jim,
You are kidding? Right? Do you really agreed with this? This is
contrary of your SSP proposal. The above is not the chartered proposal.
I hope we don't get lost into some undefined reputation concept.
IMO, DKIM will not widely adopted with a
On Fri, 23 Dec 2005, Mark Delany wrote:
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
Not necessarily. One of the proposals that went into DKIM had characteristic
of storing public key fingerprints in dns. This seems quite close to DK but
has a number
On Wed, 21 Dec 2005, Harald Tveit Alvestrand wrote:
--On onsdag, desember 21, 2005 05:36:08 -0800 william(at)elan.net
[EMAIL PROTECTED] wrote:
I also think that if allowed to be presented alternatives to putting
public keys in DNS, those would technically be found superior and less
damaging
On Sun, 13 Nov 2005, Tony Hansen wrote:
To get past the contentions around SSP, I'm wondering if we should
change the wording slightly, as follows.
Tony Hansen
[EMAIL PROTECTED]
Barry Leiba wrote:
-
DRAFT
On Fri, 28 Oct 2005, Jim Fenton wrote:
Stephen Farrell wrote:
In an offlist exchange with Doug I asked him whether he thinks
the following scenario is an example of his perceived problem
with ssp. He said it is an example, so I wanted to check with
the list about this.
1. Alice works for
On Sat, 29 Oct 2005, william(at)elan.net wrote:
It probably does lack one thing: a way of defining default policy for
addresses that don't have a user-level record.
DNS takes care of that with use of wilcards, i.e. you make a pointer to
username._user._policy.example.com
and enter
*._user
On Wed, 26 Oct 2005, Stephen Farrell wrote:
That I think is a fair enough point and worth discussing. (As might
be whether or not to allow an option for public keys to be included
with signatures.)
Please do (discuss it at the very least).
OTOH it seems that there should be a benefit to
Am I correct in reading the latest SSP draft that:
1. It changes the originator entirely to From and now instead of using
Sender header field value (as per RFC2822) to decide cases of multiple
From addresses, the first one in From header field is used?
2. It changes the meaning of 3rd
On Wed, 19 Oct 2005, Michael Thomas wrote:
The only way to have the length specifier not be a security
vulnerability is to require all verifiers to strip all content that
exceeds the length.
Which is to say that today (eg, pre-DKIM), any inbound MTA ought to strip
all content.
Correct?
On Wed, 19 Oct 2005, Earl Hood wrote:
On October 19, 2005 at 10:29, Douglas Otis wrote:
This opportunistic approach can be improved by specifying the role of
the signer, such as:
- Originating
- Resending
- Verifying
Is Resending only for entities that re-submit a message into
the
On Wed, 19 Oct 2005, Michael Thomas wrote:
william(at)elan.net wrote:
On Wed, 19 Oct 2005, Michael Thomas wrote:
The only way to have the length specifier not be a security
vulnerability is to require all verifiers to strip all content that
exceeds the length.
Which is to say that today
2005, william(at)elan.net wrote:
On Mon, 17 Oct 2005, Jim Fenton wrote:
This is a difficult question, because anything we do to accommodate
mailing lists introduces new vulnerabilities. Anything that accommodates
the addition of ads by mailing lists (since some are
advertising-supported
I noticed that when I receive replies to the posts made on this list,
they come directly from whoever replied, but I seem to not receive
typical extra copy from the email from mail list itself. Is this true
of how this list is configured?
If this is so does mail list determine it based on my
On Mon, 17 Oct 2005, Jim Fenton wrote:
Is that the same as saying that for purposes of forgery protection (rather
then establishing some identity for reputation/accreditation by means of
the signature) DKIM focuses only on the From header field?
[Yes I understand its not 100% only from in
unless you can back it up with pointers to documents publicly released at
that time.
-Original Message-
From: william(at)elan.net [mailto:[EMAIL PROTECTED]
Sent: Friday, October 14, 2005 7:08 PM
To: Hallam-Baker, Phillip
Cc: [EMAIL PROTECTED]; Stephen Farrell; ietf-dkim@mipassoc.org
On Tue, 23 Aug 2005, Hallam-Baker, Phillip wrote:
This doesn't help for BCC recipients at the same domain.
The only way to sign BCC in my view is to provide a per user signature
constructed by means of an HMAC.
For example message is Hello World, Sending it to [EMAIL PROTECTED]
So I
On Tue, 23 Aug 2005, Keith Moore wrote:
no, it just means that the MTA has to transmit multiple copies of the same
message to the same SMTP server, differing only in their signature and bcc
header field.
My understanding is that BCC should not be seen in SMTP transmission,
except first hop
On Wed, 10 Aug 2005, SM wrote:
Isn't a Joe Job messages that state false authorship in order to damage the
reputation of a domain?
Please define joe job and explain why you think this can or can not be
considered subset of or equivalent to email identity forgery.
Please also list what
98 matches
Mail list logo
