On 2/12/2018 12:40 PM, John R. Levine wrote:
Just for fun I sent in a new I-D of the dkim-conditional draft that
takes out version numbers and adds feature tags in a backward
compatible way.
https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/
+1.
But just for fun? I wish you wou
+1.
I think there are parsing issues to be highlighted. Do you decode
first, then extract the Author Domain or extract first before
decoding? etc.
On 12/5/2017 10:27 PM, John R. Levine wrote:
If I may change the topic for a moment ...
I'm working on some stuff for ICANN to help people ge
not require you to accept the mail for the hard reject policy
(-ALL).
Hector, the reality is that most mailbox providers do not reject on SPF -all because so
many senders don't understand what they are "saying" with -all and the mailbox
providers are the ones who get the com
On 11/16/2016 1:09 PM, Terry Zink wrote:
This means ARC will be needed not only for mailing lists which modify the
header or
body of an email, but for EVERY mailing list and EVERY forwarded email or
EVERYTIME
the recipient has been modified and the email leaves the ADMD boundary. From a
DMARC p
On 11/16/2016 8:03 AM, Murray S. Kucherawy wrote:
That's not correct. The verifying MTA, if it doesn't know the new
tags, is unaffected by the new tags because RFC6376 directs the
verifier to ignore them. It's as if they weren't there.
Do you have any data with unknown tag recordings addin
On 11/13/2016 1:50 AM, Murray S. Kucherawy wrote:> I've posted a draft
that attempts to address an attack that's begun to
appear with DKIM. Interestingly, we called it out as a possible
attack in RFC6376 and even RFC4871, but now it's apparently happening
and being annoying enough that people (I
On 5/13/2015 3:19 PM, Hector Santos wrote:
> There are several ways to offer the DKIM key size expectation for
> Receiver local policies to deal with:
>
> 1) Report the bit size in Authentication-Results (Auth-Res) header.
>
> Authentication-Results: mail.example.com
&
There are several ways to offer the DKIM key size expectation for
Receiver local policies to deal with:
1) Report the bit size in Authentication-Results (Auth-Res) header.
Authentication-Results: mail.example.com
dkim=pass . bitsize=num-bits;
2) Add a DMARC tag extension "ess="
On 5/13/2015 7:31 AM, Scott Kitterman wrote:
>
> DKIM is a security protocol. I find it very odd to claim that the security
> part of a security protocol isn't part of the protocol.
Good point. But we did take it into account. As you point out, the
APIs seem to have limited the size.
> While I
On 5/13/2015 1:25 AM, Roland Turner wrote:
> On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote:
>
>> https://sourceforge.net/p/opendkim/bugs/221/) appears to agree with
>> what I'm saying above. When talking about unacceptably small keys,
>> the "unacceptable" decision is not made by the protocol,
IMO, this suggestion would be better as an Informational and BCP note.
I don't think it warrants a change to STD76.
We went through this already. We (DKIM WG) were well aware of the
weakness of a smaller key but we had backward compatibility concerns
so the proper verification migration pat
On 5/12/2015 11:31 AM, Martijn Grooten wrote:
>> Why remove 512 support from the verification side? Does this mean the
>> verifier will take valid 512 signature and make it invalid, no signature
>> message? Is there a correlation out there that 512 bits signers are more
>> prune to be Bad Guys? S
STD76, DKIM is an Internet Standard, already has a Signer/Verifier
migration path in section 3.3 towards the higher key with backward
compatibility support for the verification of the smaller key.
Why remove 512 support from the verification side? Does this mean the
verifier will take valid 51
theoretical exploit in action and its
easily addressable with all the current DKIM features and options.
On 5/12/2015 8:56 AM, Scott Kitterman wrote:
> On May 12, 2015 7:28:25 AM EDT, Hector Santos wrote:
>> -1
>>
>> Please stop! No more DKIM code changes ok? The IETF just m
-1
Please stop! No more DKIM code changes ok? The IETF just made it a STD.
Maybe we should remove the STD status first, move it back to proposed
standard or experimental if this and other changes are coming.
If signers want 1024 bits, then can do so ready.
--
HLS
On 5/11/2015 1:06 PM, Scot
On 9/12/2013 3:28 PM, Dave Crocker wrote:
>
> There seems to be a pattern that has developed, of demanding that
> failure mean literally no adoption. It doesn't mean that. It means
> that it has no community traction. ADSP more than qualifies on the
> pragmatics of failure.
>
> d/
>
The pragmat
This will require a substantial review before any change of status is
done and should be done as part of WG working on Domain Policies.
There is already substantial work with ADSP and APIs implemented and
deployed. We continue to get world wide usage of our ADSP zone record
generator wizard:
On 8/4/2013 4:35 PM, Pawel Lesnikowski wrote:
> There are few details I'd like to clarify.
>
> Body hash for this message is correctly computed by the sender.
> Entire signature of this message in fact valid - this is why Port25,
> Gmail, and Mail.dll validate DKIM signature with 'pass' result.
>
On 7/2/2013 10:11 AM, Murray S. Kucherawy wrote:
> On Mon, Jul 1, 2013 at 12:24 PM, Michael Deutschmann <
> mich...@talamasca.ocis.net> wrote:
>
>> On Mon, 1 Jul 2013, Alessandro Vesely wrote:
>>> Well, not really. MAIL FROM: is only visible after delivery, so to
>>> avoid dangling signatures on
Oh, I didn't know there was a requirement for one to have IMPLEMENTED
and DEPLOYED proposed protocols before one can have any sort of
engineering insight into problems and their resolutions? I'm sure that
is not what you mean.
Sure, it helps, but keep in mind DKIM itself was engineered with li
There are a number of domains supporting ADSP, ATPS and ASL records.
There is a healthy set of world-wide usage at our ADSP Wizard [1].
The problem is I doubt anyone is "ACTING" on any strong policy rule.
That was one of the chief complaint among the policy advocates (vendors)
with the first se
M overview
(RFC5585) informational publications. Perhaps some update in the future
can correct this design and market inconsistency and explicitly provide
knowledge of the alternative frameworks available for DKIM.
--
Hector Santos, CTO
Santronics Sof
Our "extant" product supports AUTH-RES for DKIM and ADSP. Without a
thorough review again and confirmation, I feel, unfortunately, probably
not 100% according your specification. At the time it was implemented,
over a few years ago, I had found it inadequate to cover all bases. I do
recall it
Barry Leiba wrote:
>
> That said, I'm inclined to agree with Mike T that input from the
> reputation target is suspicious, so it's not clear how much value it
> will have nor whether it might be gamed (by the reputation target) or
> hacked (by someone wanting to hurt the target's reputation).
It
Murray S. Kucherawy wrote:
> On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker wrote:
>
>> Here are two small tweaks that might correct things:
>>
>> y This domain is testing DKIM. Verifiers MUST NOT treat messages
>> from Signers in testing mode differently from unsigned email.
>>
John R. Levine wrote:
>> I've opened a ticket to arrange that "t=y" suppresses any positive impact
>> domain reputation has in the next version of OpenDKIM, as an experiment.
>
> I'm inclined to leave well enough alone. That wouldn't have been an
> unreasonable interpretation six years ago when
Murray S. Kucherawy wrote:
> And you thought this list was dead.
>
> I was asked to consult recently on some DKIM questions raised by a customer
> of a former employer. The questions involved the meaning of "t=" in DKIM
> keys and the text in RFC6376. The focus of this tag has always been, to
>
stalled customer servers. In the mean time, here is
our auto-responder email address:
dkim-autoresp...@isdg.net
And for those with OpenDKIM setups exploring this, we have a wizard at
this URL to help prepare your records:
http://www.winserver.com/public/wcadsp
--
ad of member's submissions.
--
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
y our needs...
>
> Apropos rocket science, at our current rate of progress we risk
> outliving the Space Shuttle program.
>
>
> Mark.
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rule
- break it enough to
make sure there is controversy and conflict to create an IETF no
consensus.
Hey, I'm all for proving me wrong. Please do so.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: T
as a Work-In-Progress still missing a viable
> policy layer.
+1. But 5+ years WIP? :) It wasn't rocket science.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates ac
ning local mail pickups.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Michael Deutschmann wrote:
> On Wed, 27 Jul 2011, Douglas Otis wrote:
>> Your fix will not control phishing or spoofing abuse and would expose
>> these domains to open-ended sources
is a
> function of the number of clients (malicious or otherwise) rather than
> the address space they use. Are you anticipating a larger number of
> new SMTP clients as a consequence of IPV6?
>
>
> Mark.
> ___
> NOTE WELL: This lis
valid signature requirement
as outlined in section 6.0, a verifier SHOULD NOT treat a message
that has one or more bad signatures and no good signatures differently
from a message with no signature at all.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
t, and what other information they
> take into account is carefully not said). The malicious signer is hoping
> that the treatment his scam gets is favourable enough to get past the
> assessor unscathed and so reach that lenient MUA, where the real damage
> happens.
>
>
cted.
Michael Deutschmann wrote:
> On Sun, 10 Jul 2011, Hector Santos wrote:
>> Now of course, if ADSP was a standard and whitehouse.com had an
>> exclusive signing policy, receivers would of rejected the junk
>> distributed by Dave's list server as an ADSP violation. But
pects of
the protocol BROKE down when it was separated and we never got over it.
--
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
/receiver can do a lot here,
but I personally don't like to be playing these games and we don't
know how other software will behave, so I would prefer to just kick
out damaged mail - even when its possible to validate one of the
multiple froms.
--
Hector Santos
dress legacy signers and verifiers, which
includes receivers or internal mail creators don't allow multiple from
headers.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates a
he h= setting to be
flexible for the operator, then they can add it (we add it by default)
as a short term solution. In the long term, I don't think it has to
be used, but then again, I am strongly basing that that most DKIM
implementations will eventually use a ONE FROM RULE
correct, including time wise, given the fact
the payload is 100% exact?
Just wondering how much time I should spent on what appears to be one
of the final considerations for our new revision of DKIM implementation.
Thanks
--
Hector Santos, CTO
http://www.santronics.com
http
egrate it with DKIM and they need to dot all the eyes, cross
all the t's in their integration. If they have software control of
their DKIM stuff, its probably a good idea to make their the Verifier
and Signer has a One From DKIM Rule concept as cited in my previous
post and the specs
gt; time [...etc...]"
>
> Barry, as participant
> ___
> 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
Its a
complex beast. But completing it, at the very least, I can use the
"official completion announcement" as part of our marketing.
PS: We resolved the overhead issues with DKIM signing so we are now
ready to go. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.bl
er. We need to deal
with that, for sure, as a highlighted signer recommendation targeting
list mail. But as the table above shows, without the fix it
doesn't matter.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Alessandro Vesely wrote:
> On 27/May/11 19:16, Murray S. Kucherawy wrote:
>> I'm all for including experimental code in future releases of our
>> stuff, especially if it's an experiment other implementations are
>> trying. But I need to see a spec first, or enough detail that I
>> could write one.
Alessandro Vesely wrote:
> On 25/May/11 20:23, Dave CROCKER wrote:
>> That's not likely to be the goal of this sort of exercise. Rather, it
>> will be to choose a set of particular types of breakage, ignoring others.
>> For an effort like that, it is not meaningful to come up with additional
Hector Santos wrote:
> MH Michael Hammer (5304) wrote:
>>
>> Remember, it's not static, it's dynamic. What was a non-phished domain
>> yesterday could be a phished domain today or tomorrow. DKIM isn't a
>> magic bullet, it's one more tool in the tool
Who it
happens to (the messenger), is a very important factor in all this.
--
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
Hector Santos wrote:
> John R. Levine wrote:
>
>> These days most subscriptions are entered on a web page, and if you're
>> lucky the mailer will send a confirmation message with a URL that sends
>> the subscriber back to the web page. Where's the MTA go
ombination with SPF it works very nicely on double fail and none/fail
> as far as catching badness with very little impact on legitimate mail.
>
What sort of phishing are we talking about? Identities or the context?
--
Hector Santos, CTO
http://
target that includes the address you directed replies to.
--
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
our own local side lists, not others and
that will scale just fine. The only thing is that it may be two
separate applications (SMTP and MLS) so interfacing them would be an
implementation question. Generally, an accept or forwarding file is use
n its
checking especially with the terrible accept/bounce problem everyone
is trying to avoid with SMTP rejects.
I am just saying, it will help to know to some extent what is the make
up of the collection you have from a pre-filter standpoin
. Before that, it was
in the 1-4% range.
So if most of the 6% SPF rejects are spoof attempts on our domains,
then I have no reason to believe that DKIM plus our ADSP/ATPS/ASL
policies would not yield the same result.
Hector Santos wrote:
> MH Michael Hammer (5304) wrote:
>
>> The ot
t, but I am going to try turning off SPF for my domains and see if I
get the expected 100% "would-be" rejects based on DKIM and my ADSP
policies.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
__
r specific LIST-ID among other things for acceptance or
rejection. But thats local policy and not a stock script we distribute.
And now with DKIM, I am exploring similar scripts checking LIST-ID to
match the signing side where the List-ID is used for signing specific
list only when its going o
have an official
SMTP reject, and want the list server to create a non-bounce
notification. But I can see where this be a good idea to do now -
SMTP level rejects with response text "User not member of so and so list."
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blog
nless all the list
software and/or operators add Plug and Play hooks, to do the "Always
Resign" thing you want, we will always have the problems for a very
long time.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
John R. Levine wrote:
>> Perh
check for member subscription.
I guess if the RECEIVER is a List Server SMTP Server, then its
database will be easily accessible to do a member check at SMTP level.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE W
Steve Atkins wrote:
> On May 26, 2011, at 1:50 PM, Hector Santos wrote:
>> If by traditional, you mean the members are vetted with subscription
>> and confirmation, then this tends to be true. But when not, when the
>> list or any group forum is anonymous in nature, histo
irmation, then this tends to be true. But when not, when the
list or any group forum is anonymous in nature, history has told us
its get corrupted with junk and most people tend to dislike it.
--
Hector Santos, CTO
http://www.santronics.com
http://sant
one reason only - you can't assume everyone
is going to resign yet alone add DKIM to their software.
--
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:
> On 26 May 2011, at 12:46, Hector Santos wrote:
>
>> In principle, passthru mail should not be tampered, but MLM list mail are
>> the industry accepted exception to this non-tampering tradition and today
>> (at least in the USA), it is CAN-SPAM leg
ly
one of the simpler C14N issues to deal with. It may be minor, but it
still an issue for a LIST that DKIM mail passes thru. I feel should be
part of a DKIM C14N consideration and also an MLM awareness issue, not
necessary for my sake but for DKIM sake.
--
Hector Santos, CTO
http://www.santro
essage [Click for Signer Options]
then the exclusively mutual (radio) option is automatically unchecked.:
(_) Keep Original Submission Integrity
because it doesn't matter any more when the MLM is always (re)signing.
Anyway, IMV, what people need is insights and let them make their own
decisions b
ely, it also comes with a change
requirement.
At the end of the day, no matter what, people software (Old and New)
need to change to make DKIM work better.
--
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
Alessandro Vesely wrote:
>> Hector wrote:
>> 4 - Lines over 998 (1000 with CRLF), this is an invalid RFC5322, but
>> its possible some verifiers are designed to do a buffered C14N
>> and don't check for RFC5322 line lengths between two memory points
>
ven if
TBIRD doesn't have its own table, when the user tries to save it,
Windows will most likely make the shell association.
BTW, under OE, while it does show the SMIME.P7S icon attachment, the
message display is blank. That may be related to what you are talking
about. In any case, i
Scott Kitterman wrote:
> On Wednesday, May 25, 2011 02:04:45 PM Hector Santos wrote:
> ...
>> When I remove the domains I know, the rest is pretty much spam.
> ...
>
> Isn't that pretty generally true, DKIM or no DKIM.
Sure, in general I would agree with that and m
% failure
NEW: 4.8% failure
and the major contributor to this is that I have no more
facebookmail.com failures!
When I remove the domains I know, the rest is pretty much spam. :)
Hector Santos wrote:
> Alessandro Vesely wrote:
>
>> For example, MTAs that autoconvert from quoted-print
ng:
>>
>> 5 - Incorrect handling of lines beginning with dots, for example
>> I sent a message containing a line beginning with:
>
> Yes, dot is one of the punctuation characters that should be removed.
This turned out to be a bug in our beta code, r
Alessandro Vesely wrote:
> On 25/May/11 10:03, Hector Santos wrote:
>> How would 7/8 bit be considered?
>>
>> Personally, the STRIP C14N idea would work just fine by removing all
>> trailing WSP (CR, LF, SP) and for QP text, decode it first. I'm
>> consi
e encountered.
- MLM that add an extra line at the top (possibly because of any
empty
header file of size 2, crlf)
- Intermediaries that expand QP to 8 bit
- Intermediaries that reformat to BASE64
I personally have not seen anything else.
--
Hector Santos, C
l agree it's fine.
Not in Thunderbird V2.0, V3.1. It knows nothings about your signature
- Click View | Message Security Info and it says:
Message Has No Digital Signature
Message Not Encrypted
What version of TBird did you use?
--
Sincerely
Hector S
rnet for
>> Dummies",
>> Please consider the environment before reading this e-mail. http://jl.ly
>
>
> _______
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>
--
Hector S
Franck Martin wrote:
>> Steve Atkins mentioned:
>>> This (entirely RFC valid yet completely broken) behaviour has bitten me
>>> a couple of times.
> Hector followed up:
>> +1
>>
>> If everyone (mail transport/mail handlers) just followed the basic
&g
t in principle, intermediaries need to refrain from
thinking they know better for downlinks.
hmmm, perhaps "DKIM Scouts" :)
--
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
are
seeing it now, its because of this DKIM integrity invention highlight
the issues.
--
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:
> On 23 May 2011, at 17:10, Hector Santos wrote:
>
>> Rhetorically, why not? Put another way, why should a receiver
>> tolerate failure, or better, why should DKIM itself - the technology
>> - tolerate failure? Sounds like DKIM has some inner soul t
ernet for
> Dummies",
> Please consider the environment before reading this e-mail. http://jl.ly
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.
is pretty much nothing.
--
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
heir own bee's wax if they see an unexpected, unsolicited, unknown,
unauthorized non-first party DKIM signed mail when the author domain
may have a policy that says "Thats a NO NO"
Dave, you got receivers all twisted up in knots!
--
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
Alessandro Vesely wrote:
> On 23/May/11 06:35, Hector Santos wrote:
>> Alessandro Vesely wrote:
>>
>>> For example, MTAs that autoconvert from quoted-printable to 8bit, a
>>> rather common circumstance.
>> I did the following Content-Transfer-Encoding failure
Ian Eiloart wrote:
> On 23 May 2011, at 15:19, Hector Santos wrote:
>>> But why skip? Usually the message won't be downgraded. And even if they
>>> are, usually a broken signature will cause no harm.
>> Thats the problem - define "usually" and also de
ange and even within the core headers, it definitely
should avoid signing headers that are guarantee to change based on a
known path it will take - like for an MKM, consider not hashing the
5322.Subject tag and use "l=" when the target path is known to be a
list adding a footer.
So with th
Ian Eiloart wrote:
> On 20 May 2011, at 05:24, Hector Santos wrote:
>
>> In this case, if this is enforced with a MUST, for a system that is
>> not 8BITMIME ready but is adding DKIM signing support, to remain
>> compliant it is far more feasible to add a rule to a DK
Charles Lindsey wrote:
> On Mon, 23 May 2011 03:50:06 +0100, Hector Santos wrote:
>>
>> It would of been nice to have some DKIM-Signature flag that might
>> indicate the Content-Transfer-Encoding, i.e.:
>>
>> et="base64" <--- copy of the top
oing thru a list.
It would be interesting to see what Murray can show for his volume
collection.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dki
rs do not
have a common source to do this and even then, they may only want to
do this for selected VBR records, Author Domains and signers.
--
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
nbase64 before hash verification.
Of course, it still would of failed due to the list footer so, but if
l= was used, there is some avenue for success.
The main realization is that Sender/Signers need to be more aware of
the target/path if they desire a higher rate of return.
--
H
Murray S. Kucherawy wrote:
> Hector Santos followed up Crocker'ss passing of the buck:
>>
>> Please refrain from passing the buck to the WG. The document editors
>> are:
>>
>> D. Crocker (editor)
>> Tony Hansen (editor)
>> M.
sign mail
While that may be a functional description of a fallback, we don't
have the automated technical capability to define it reliably.
--
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
synergism with past or concurrent document productions, lost of WG
interest participation with a resultant Consensus by Osmosis process,
and frankly, all of which, all reflected a mark of poor leadership.
In this case (8BIT Downgrades), it is my view the SHOULD language is
fine and was quite fitting the understood technical feasibility realities.
--
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
y ignore unlikely domains |8.13 | | |X| | | |
| | | | | | | | |
+---+
FootNotes
1. No explicit statement for signer and sha1
2. is a NULL string an asciiz Str
r and before the beginning of the body content.
See the slippery slope?
What do we expect will happen in the future when the MLMs are more
DKIM aware, and the 8bit streams are not altered to the extent that
DKIM faults are negligible and this MUST is now doing need
Pete Resnick wrote:
> On 5/19/11 6:52 PM, Hector Santos wrote:
>> SHOULD is an optional requirement - Its a recommendation for the
>> better, but things will not break things for your peers if you don't
>> follow it. You may be shamed but the person shaming you i
We don't have any great insight into the warts
> of what paths are likely to downcode a message and what paths aren't,
> so I would prefer not to purport to offer advice about it.
We do have great insight - Don't Tamper with Passthru mail - that
should be the advice burn into sy
LD be converted to 7-bit MIME by an MUA or MSA
prior to presentation to the DKIM
So I don't even know why we are talking about this. If its out of
scope how we can contemplate a MUST here. I concur with Levine, take
it out.
--
Hector Santos, CTO
http://www.santronic
1 - 100 of 1672 matches
Mail list logo
