to outright reject in-transaction.
And that is the only mission I care about.
Michael Deutschmann mich...@talosis.ca
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
not trigger on those
two cases.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to the bad guys.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
that
those are deployable senderside.
TPA ADSP enhancements are tier 1 receiverside and just-barely-above tier
3 senderside. They could be as powerful as except-mlist in terms of
false-negative rate where deployed at both ends, but require much more
elaborate setup work at the sender.
Michael
DKIM is only tasked with determining if a signature is genuine, not
if the signature is relevant. Therefore it doesn't matter if part of the
information EDSP uses to determine relevancy is out of band.
Michael Deutschmann mich...@talamasca.ocis.net
they be tempted
to do that?
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
present. Any other behavior would fall under false negative due to
irrelevant signatures.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
poster's EDSP will be correctly ignored.
Just like in SPF.
Of course, since the MAIL FROM: is usually not visible without pressing a
show all headers button, this would be more about leaving a clearer
audit trail than actually foiling phishes.
Michael Deutschmann mich...@talamasca.ocis.net
to declare that all mail bearing my RFC821 MAIL FROM:
without a corresponding signature is bogus while saying nothing about
that which merely bears my RFC822 From: would be a good start.)
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL
time. The sender loses
utterly.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to the world
with just unknown and discardable. (I'm not counting all since it
is too vague...)
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
Consider SPF. SPF does nothing to prevent phish, as it only protects the
MAIL FROM: address which is not presented to the user by default. Yet
receiverside SPF deployment has progressed further than ADSP, because SPF
does kill some spam.
Michael Deutschmann mich...@talamasca.ocis.net
is not to control phishing. That's
just a side benefit of their true goal, to control forgeries. When
forgery can be reliably detected, it becomes a low-false-positive noise
filter, something every MX admin loves.
Michael Deutschmann mich...@talamasca.ocis.net
less
convincing than a simple unsigned forgery. Failure 3 produces a result
no more convincing than the simple unsigned forgery.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
in his MUA, then he is unlikely to be vulnerable.
(and that doesn't even consider all the fuss we've made here about this
angel on a pinhead...)
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http
a message based on all appropriate signatures being present for
just one instance of the header, and yet a downstream entity falsely
assumes a different instance was so validated.
}
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list
-From: messages, then you don't
have the power to demand that they deploy DKIM at all.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
. Those are hard problems, the DKIM people should not have
to be weighed down working on them.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, and not my
address.
(If he used a list I subscribe to, he still loses. My exceptions are
keyed on the MAIL FROM:, and SPF guards that.)
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
for a message
containing a message/rfc822 element under 8bit CTE (which *is* legal),
simply isn't defined.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
using either the quoted-printable or
# base64 encodings.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
protocol is higher
priority than writing the certification standard.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
for such a certification, but not in the draft at issue.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to ADSP and your
enforcement of a unique From:, to make such a document viable.
Otherwise phish-targets won't offer sufficient reward to be worth the
tech-support hassle of being unable to disable ADSP (lest they lose
compliance) at the request of a user with a false-positive problem.
Michael
. Providers of F2F will likely give up and use
original From: addresses before end-users give up and (force their BOFH to)
undeploy ADSP. But the mailing list problem for ADSP is even bigger than
SPF's forwarding bugaboo -- it utterly scares off meaningful senderside
deployment.
Michael
signatures, means that the obvious implementation would have an
unacceptable false positive rate.
So we need to make a hole -- hopefully as small as possible -- in our
ADSP-like protocol so that mailing list traffic can get through.
Otherwise no one will deploy it in a useful way.
Michael
*all*
messages, then re-insert the Full Name as listed in the user's address
book if there is any match against the real address.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
for PayPal. All it does is make him more likely to notice by
removing the distraction of an exactly-as-expected full name.)
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf
as *@paypal.com forgeries.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to be a
molehill. If widely used, the double-From: would quickly appear in
SpamAssassin and the like -- one doesn't even need to do any
cryptographic work to detect and block it. In contrast, detecting false
full names would require some sort of registry that does not exist at
present.
Michael
the gullibility of their users,
including techniques outside the scope of DKIM. Such as any kind of stab
at solving the human-name problem I've highlighted (but that's a huge can
of worms), or suppression of attacks using lookalike domains.
Michael Deutschmann mich...@talamasca.ocis.net
hand over their keys
But DKIM presently has the lawyer's car parked in front of its driveway,
and can't complain because that car parked before the house was built.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates
posts to the list, but for other
reasons, modern lists make it a requirement to opt-in subscribe and then
suspend delivery, should one want to post without reading.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates
the heck is it good for?
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
. Adding a Cc: header listing the original From: address would
help with that.)
The fact that this would work brings up a separate flaw in DKIM that I
believe has been mentioned before. There's not much of a solution to
it, though.
Michael Deutschmann mich...@talamasca.ocis.net
blackholed (thus making diagnosis of an
FP-causing configuration error harder). So an MX capable of validating
before responding to CR LF '.' CR LF may treat them identically.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates
the user subscribed to, there
is a significant security-by-obscurity effect that means one is likely to
get away with trusting a list that is forgeable. LDSP would make
things more reliable, but would never be the essential component.
Michael Deutschmann mich...@talamasca.ocis.net
didn't have the inclination to deploy the
thing, will go straight through.
The bag is guaranteed to keep you alive, but you'd be a fool to use it in
battle.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according
directed at me*,
and the use of dkim=unknown or no-ADSP by those other people hampers my
ability to achieve that. I don't need them to go whole-hog TPA, I just
need help squelching the supposedly-first-person forgeries, and I can
take care of the supposedly-via-list forgeries myself.
Michael
, recipients will disable
incoming DKIM filtering to avoid false positives. Everyone loses.
Are ISPs normally phishing targets?
They aren't, but that doesn't mean I want to see messages forged to be
from their users.
Michael Deutschmann mich...@talamasca.ocis.net
, many big sites will never compile the information needed to
display a complete TPA policy. Without accomodation (ie: except-mlist),
dkim=unknown is all they can safely publish.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list
.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
they are subscribed to.)
Sure, you can try to force all mailing lists to go through some signing
ritual. But if the mailing lists were that willing to bend to
accomodate DKIM, they could already accomodate the published RFCs by
rewriting the From: on the messages they forward.
Michael
On Fri, 25 Jun 2010, Dave Crocker wrote:
On 10/16/2009 3:33 PM, Michael Deutschmann wrote:
I'd like to more emphatically state the case for adding a
dkim=except-mlist policy to ADSP. It will soon become a practical
issue for me, since my mailserver software (Exim) is going to support
like mine *do have the needed intelligence*.
The only further knowledge they need, is which sites are publishing
unknown because they don't sign everything yet, and which sites are
publishing unknown solely because of the mailing list problem.
Michael Deutschmann mich...@talamasca.ocis.net
lists
2. Senders who recklessly assume that all is universally treated
as except-mlist
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
it differently from
unknown; only vanity-domain recipients can benefit. But it would be
correct for a mailing list input mailserver to treat except-mlist as
rejectable, since lists don't mail to each other.)
Michael Deutschmann mich...@talamasca.ocis.net
to other lists.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to settle the fight over what all means, let's just
deprecate it and give each camp their own, *unambiguous* flag.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
* and close the book,
it just might stay closed...)
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
them specifically.
This would allow 100% backwards-compatible later deployment of schemes
that provide for easier detection of desired mailing list traffic.)
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates according
recourse to some hypothetical third-party-signatures
standard (which will likely flop among ML admins just as SPF's SRS flopped
among forwarders...). dkim=except-mlist is all *we* need.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL
On Mon, 12 Oct 2009, Wietse Venema wrote:
Michael Deutschmann:
If this is indeed the official semantics of the protocol, then I would
petition to add a dkim=except-mlist policy. Which means I sign
everything that leaves my bailiwick, but may post to signature-breaking
MLs.
Are you
option, that provides for silent discard
of mail that fails DKIM and is clearly not legitimate mailing list
traffic. But I don't think anyone would ever use it.
Michael Deutschmann mich...@talamasca.ocis.net
___
NOTE WELL: This list operates
On Sun, 11 Oct 2009, Michael Thomas wrote:
On 10/11/2009 02:41 AM, Michael Deutschmann wrote:
If this is indeed the official semantics of the protocol, then I would
petition to add a dkim=except-mlist policy. Which means I sign
everything that leaves my bailiwick, but may post to signature
On Sun, 11 Oct 2009, Dave CROCKER wrote:
Michael Deutschmann wrote:
While I don't think the Hector/Levine interpretation is very useful, I
think it would be a sound strategic move to yield to them regarding
dkim=all, and instead create our own dkim=except-mlist space where our
semantics
57 matches
Mail list logo
