If the signature is valid *and* the signer has a good
reputation, then a delivery agent might do something nice to the
message. If it sees a lot of cruddy mail with my signature,
The issue is not your 'signature' but your d= domain name. That's where
the reputation assessment is supposed to
I don't know anyone who's checked whether DKIM validators verify the
version number, but if it's an issue, there aren't that many widely
used DKIM engines so it wouldn't be hard to check.
Just FYI, libdkim which all our products use does check the v= and if
it's not v=1 verification fails
sigh, stupid editor. As I was saying:
I can think of a variety of ways to get this effect by hacks that stay
at v=1, all rather ugly. For example, we could invent
pseudo-canonicalizations like c=condrelaxed/condsimple which are the
same as relaxed and simple, but only are valid if the verifier
Here's an example. The top signature is from the list, the second and
third signatures were applied by the sender. The second is the normal
signature and the third a weak conditional signature. The third has
cs=fs which means it's only valid with an additional (forwarder)
signature, and fs=t
I'm not sure we need to be considerate of such behavior. If it's
malware, reject it outright.
Can't do that. Many viruses attach themselves to legitimate messages.
If the author is the boss, rejecting it would be, uh, bad.
I don't think I've seen malware attached to a real message in the
When DKIM-Delegate is used, there are two, valid signatures for the same
domain. One is 'stronger'.
The scenario being discussed is for a recipient who gets both signatures
when they are valid, but who does not know about DKIM-Delegate. They
only know about DKIM.
That's not a problem -- if it
If a signature has an rsf= tag, verifiers ignore it unless there's a
matching signature from a domain the rsf= points to.
This is not backward compatible, since verifiers that don't understand
rsf= will often get the wrong answer, so it needs a version bump.
Can't both the version
On Wed, Jun 11, 2014 at 7:15 AM, John Levine jo...@taugh.com wrote:
Right. So if you don't want people using unforwarded weak signatures
for reputation management, you need to put something into them so that
old clients don't accept them as signatures and ignore the t= tag.
Either call them
In article caba8r6ttzt+vtv4oqvx-s7desv+cu72xm9-pcazt3+m6ecb...@mail.gmail.com
you write:
-=-=-=-=-=-
-=-=-=-=-=-
Let me see if I understand this... you want to be able to use a strong
DMARC setting for your domain, and let YMail send mail on behalf of your
domain?
I think the use case here is
But that is not equivalent to putting non-resolvable gibberish on the right
side of the @ sign. That's
a reliable way of assuring that such messages do not get queued on my server.
As a matter of
practicality, I highly doubt that I'm unique in requiring that the sender
domain (envelope and
Otherwise it is easy to send an email with a domain that contains an
extra letter and bypass DMARC.
It is ALWAYS easy to send an email with a domain that contains an
extra letter and bypass DMARC. Lookalike or cousin domains are
specifically not something it addresses.
Keep in mind that is
The OAR isn't necessary for a DMARC compliant MLM which would know to
make sure the message passed DMARC as sent by following one of the
mitigation strategies (don't munge the message, munge the from, embed the
message as an attachment, etc). It seems necessary for any whitelisting
scheme,
Even if I grant you that (and I'm not sure I do), I also don't know why OAR is
better than AR.
I get the impression there are two reasons for OAR:
a) A-R is likely to be stripped by intermediate MTAs, OAR isn't.
b) whoever suggested OAR didn't understand A-R semantics
Take your pick.
R's,
Yes the email is legitimate, but how does the MTA knows it?
Well a bayesian filter has learned that this type of content is legitimate,
and then one day a spammer
uses the same content, but change one link...
That could happen to any mail feature you care to name.
Big companies send buckets of
That's okay -- it was just a thought. However, note that not all MLMs
are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it
might be useful.
I wouldn't count on it. I did .invalid patches for majordomo2, which
is largely abandonware but still used a fair number of places.
I would love to see that list of multiple mitigations shared with the
broader community. That would be useful information for people in the
IETF, as well as other MLM teams not involved wherever those discussions
occurred.
Your wish is our command:
Since you don't mention it, what about the mail this article to a
friend use case that has also been mentioned? Is that a problem that
should be addressed here? ...
Franky, that case has always been kind of ick, and is easily solved by
sending From the domain in question
For a service at this scale, you'd need to only do this for places where
you trust their Authentication-Results header. There is a potential
issue of conflicting AR headers, which is one benefit of the OAR.
Its not clear to me that gmail.com needs to tell another service to trust
the OAR from a
901 - 918 of 918 matches
Mail list logo
