> > With double signing, you have the ability to distinguish between plain
> > old spammers, and spammers who are screwing around with forwarded
> > mail. I think that's a useful difference, since it is my impression
> > that the set of malicious mutating forwarders is pretty small because
> > it'
>On the inbound, I’m not sure whether or not we’d verify the DKIM v2 *or*
>simply suppress the DMARC check and apply all of our other antispam filtering,
>and update the MLM’s reputation accordingly.
Well, gee, you can do that now. We hope you do, since that will also
enable list mail from people
>> The double signing hack limits the opportunity for trouble to mail
>> systems that have a recent real message in hand. While I can
>> certainly imagine spammy scenarios, it's hard to imagine ones that
>> wouldn't be fairly easy to detect and shut down. ...
>True, the damage is limited to the l
>The challenge here is that the second signer may not have anything to do with
>the message. Since, except for From, only invisible parts of the message are
>signed, the signature could be applied to almost any email. Using the
>reputation of the second signer's domain is not substantially dif
>I would think you'd have to. There's a replay risk that's unique to this type
>of
>signature, so I think treating them the same would be a naive approach.
Remember that DMARC doesn't tell you that a message is good. The most
it can say is "not so awful that you should automatically reject it."
>> What would the Authentication-Results header look like? Presumably 3
>> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC?
>> Show one result or two? Or maybe something like dmarc=conditionalpass? ...
>Is there any use in making a distinction to your acceptance/routing of
>> Remember the key axiom of mail reputation: you cannot say good things
>> about yourself, only neutral or bad things. ...
>This is an interesting observation when compared to DKIM and SPF, where you
>only actually know something about the message when they report a "pass".
>But that's authentica
>Under at least one of the proposals, it can be determined that "yes, A
>signed the mods, and if the mods are removed to re-generate the original
>message, B signed the original message". If we have that, then I think
>the question becomes: if this is to be a DMARC-like scheme, how do we tie
>A's
>> No. Most domains aren't subject to significant phishing attacks, so
>> for them it's useful for incoming mail from Paypal et al, but not for
>> outgoing mail.
>
>I take it that a *significant* phishing attack is one where the
>5322.From domain is involved with money, and the hook is a URL at a
>Isn't the ideal objective of DMARC to be so reliable that *everybody*
>uses it with p=reject.
No. Most domains aren't subject to significant phishing attacks, so
for them it's useful for incoming mail from Paypal et al, but not for
outgoing mail.
> At that point, 5322.From addresses will all
>
In article <1552316227.113529.1431130088299.javamail.zim...@peachymango.org>
you write:
>I went over the emails of this week, did not find any new comment/update for
>the above document.
Do you know when you'll be posting a new draft? There's a fair amount of stuff
to fix.
R's,
John
___
>Is it sufficient to say something like this?:
>
>"A participating operator needs to solve the registration problem.
>Different operators will have different capabilities, requirements, and
>limitations here.
So far so good.
> A very simple approach would be ;
Not so good, since there are lists
>With List-Id becoming a more generic feedback channel, I suspect that its
>value for indicating the participation of a MLM will further degrade.
This is news to me. Can you explain or give pointers?
The only application of List-ID with which I am familiar is to sort
(or filter depending on whic
>I recall some earlier discussion about encoding information in From local
>part, but if for no other reason, automatic addition of new email addresses to
>contacts by some MUAs makes that highly problematic.
This trick also has patent problems.
>DNS query to message-id.yamfsidlocalpart._dmarc.
>Please post more reviews...
Hmmn. Section 3.1.2.3 on EAI is, to a first approximation, completely
wrong. Please delete it, since the problems it describes do not
actually exist.
EAI does not, repeat NOT, downgrade messages in transit. If I send
you an EAI message, either it'll be delivered a
> Are we going to say "The big four email providers pushed their problems onto
>everyone else" ?
Yes, of course. But as we've seen, we have little ability to push
back.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listi
>Even if we were all to concur that altering the From by adding the list is
>the right way forward here (an intriguing idea at the moment), ...
Just for the record, I haven't been responding to arguments about
rewriting the From: line because I don't any way they will lead to
anything useful, and
>Couldn't the DMARC specification spell out that Receivers claiming to be
>DMARC-compliant, when choosing to *accept* incoming messages from Senders
>publishing p=reject (irrespective of whether such accepted messages passed
>or not the DMARC checks), CANNOT after-the-fact reinject such received
>m
>yes, but the problem with cost imposed on third parties is that it is
>valued different by the one who imposes it on someone else and the one,
>on which is it imposed.
Well, sure. If I can force you to solve my problem, as far as I'm
concerned that's a free solution. I hope we agree we want t
>Rolf kind of said what I'm thinking here: I agree that we need to look at
>the costs. But are we willing, or not willing, to accept costs that are
>not zero?
Sure, everything has some cost. Something I should have made clearer
is the difference between the costs of changes one imposes on one's
>That leads to six combinations: Originator/Big, Originator/Small,
>Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small.
This is indeed useful. But I think it's also important to look at
technical vs. nontechnical costs for each actor. The whole reason
we're having this discussion
>This can be solved by having the owners of mailing lists publish a
>yet-to-be-defined DNS record in which they proclaim the presence of a
>mailing list within that domain.
That's unlikely to work, because malicious people can publish anything
that legitimate lists can.
There's a fundamental ru
>> A database is still needed of which domains will have an
>> outbound mail stream with two signatures.
Sorry, no, that's completely wrong. Please reread the draft.
>I have not yet taken the time to fully understand the "weak and
>strong signatures" idea, but if I may be forgiven for commentin
>That last sentence is basically what I said about both of my drafts, and
>that logic was shot down. Once you've decided you don't like the arbitrary
>changes, you know who to blame, but you still have to decide what you like
>and what you don't.
Yeah, now that I look at your drafts again, I see
I updated my conditional signature draft, which is now (thanks to a
suggestion from Ned Freed) the mandatory tag draft.
https://tools.ietf.org/html/draft-levine-dkim-conditional-01
The idea is that you have a weak signature on To, From, Date,
Message-ID but not subject or body, with a new tag tha
>Comments on either or both are welcome.
They both have the same problem: the list says:
Here's what I did. Whadda ya think?
Every recipient system has to come up with its own heuristics to
decide what combinations of changes are or are not acceptable, which
means that the exact same message w
In article
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Looks like we require v to exist and be either 1 or DKIM1, otherwise you'll
>get a "bad format" or "bad version" in the AuthRes header. Wonder how old
>the DKIM1 is and whether we should remove that now...
The DNS key record has to say v=DKIM1
>Handled by whom? If we're talking about telling MUAs "Don't render the
>unsigned part of the content the same way as the signed content", then a
>bunch of additional complexities begin to appear:
We went over all of this ages ago when DKIM was young. It should all be
in the DKIM WG archives.
>
In article <551cc3fe.10...@dcrocker.net> you write:
>On 4/1/2015 8:22 PM, John Levine wrote:
>>> In the latter case, it's really an entirely new protocol, which should
>>> be identified by the next-lower protocol, rather than by using the
>>> version
>In the latter case, it's really an entirely new protocol, which should
>be identified by the next-lower protocol, rather than by using the
>version field as an in-bred demultiplexing field.
I suppose, but if the two procols are 99% the same, and the new one is
upward compatible with the old one,
>As I recall this was considered during the development of DKIM originally,
>exactly for this reason. We rejected it because we couldn't come up with a
>safe description of what a tag should look like.
Yeah, that's what I recall, we couldn't figure out a way to allow benign
modifications without
>Verifiable authenticity of email greatly depends on DMARC's success. Because
>without
>DMARC's success the authenticity of email can only be verified heuristically
>and not
>systematically.
Rehashing old arguments will not change anyone's mind. False assertions are
like these are utterly usele
>But do you think the general email-using population will be happy to miss
>authentic email from eBay, Amazon, Paypal and American Airlines, just to get
>email from some mailing list(s) delivered to their inbox?
My impression is that most users put a very low value on commercial
bulk mail. I'm no
>> How big is the volume of DMARC-problematic indirect email flows, compared
>> to the general volume of email which can readily benefit from DMARC?
The numbers I've seen say that the volume of mail that DMARC screws up
is fairly low, but it is very high value.
Personally, I would be happy never
> From: "John Doe (j...@dmarc-abuser.com) via NPO"
I would try some tests particularly at AOL before I did that. AOL
mail tends to reject anything that looks like a munged AOL address.
The least painful approach may be to tell people with AOL addresses,
sorry, please get a different address.
In addition to other comments:
Section 3.1.2.3 is just wrong. EAI specifically does not allow for
downgrading of messages in transit from UTF-8 headers to ASCII
headers. The only place the header downgrade is allowed is when a
non-EAI MUA picks up mail via POP or IMAP, but that would be long
aft
>Yahoo is NOT the only one I've had issues with; hotmail is the same - a couple
>weeks and I'm
>bounced again on either from the ARSClist. Based on my experiences with Yahoo
>in the past, I'm not
>even going to waste my time CONTACTING them, let alone trying to lobby them.
The problem is that Ya
>RFC 7208 doesn't say the HELO result determines anything. It says IF (I say
>again IF) a decision
>has been reached about message disposition based on the HELO result, there is
>no requirement to go
>ahead and do a pointless Mail From check.
While that is certainly one plausible interpretation
>DMARC leverages the Mail From identity, so I don't see how independent HELO
>checks can be relevant.
If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable
interpretation is that you check the HELO identity, and if you get a
"definitive policy" result, you're done and return that to the
>Do people concur with this change, or something close to it?
I'm OK with it, but to the meta-question, I realize the practical
issues involved with yanking something out of the production queue,
but in this case I wonder if that's not the right thing to do.
There's no great hurry in getting the
>HELO results are unrelated to DMARC.
Is that still true when the bounce address is empty? It's fairly common
to have an NDR with an empty bounce address and
From: MAILER-DAEMON@flaky.example
Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user
supposed to do?
R's,
John
>Not mentioned anywhere: Which SPF modes are considered to be a "pass"
>> for purposes of DMARC? Presumably +, presumably not -, but it should say
>> something about ? and ~ if it doesn't already.
>
>Not only is that another late-stage technical issue to punt to the working
>group, but I also claim
In article
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>OK, seriously, I hope I don't have to crack this open again. Conflict
>review is slated for the 1/8 telechat, and a flurry of last minute edits
>might not sit well with the IESG. We need to leave actual work, as much as
>at all possible, to the
>I'm staring at this and not understanding how the two are all that
>different. They both seek to ensure that a DMARC evaluation can be done on
>the From: domain, and thus both seek to ensure that the From: that lands in
>the inbox can be trusted by end users to be valid.
Now, wait a minute. DMA
>What about pointing it may be a security issue to let these messages through?
Only if we also point out that it may be a security issue not to let them
through.
Seasons xmas,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/lis
>>> 1. Hotmail/outlook.com puts a green shield in the web UX in front of
>>> trusted senders
>who authenticate. Is that what you mean?
>>
>> Only sort of. That's ad-hoc since each recipient system has their private
>> list of
>green-bar-worthy senders. (I mean, if I wanted to get into it, how
>4. Anything else?
Figure out how to display signed mail from famous brands in a
distinctive way analogous to browser green bars, and tell people
to look for that.
Crooks can figure out ways to misspell Paypal faster than you can
blacklist them, and half the time the crooks don't even bothe
>So the edge system generates a bounce message (MDN). Knowing that
>RFC5321.MailFrom will "<>".
>To be DMARC compliant the RFC5321.HELO/.EHLO name must be align with the
>RFC5322.From of the MDN.
Why wouldn't you add a DKIM signature that matches the domain name in
the message From: line? The e
>>> Could I request the list admins, to drop the subject tagging and the footer
>>> on
>this list? And if possible remove the removal of the HTML?
Every IETF list I subscribe to, which is a lot of them, is set up the
same way with subject tags, message footers, and flattened text.
There is no mor
>> I occasionally see non-ASCII octets introduced by spam/virus checkers in
>> X-Spam-* fields in the header or in the (non-8-bit) message body, due to
>> copying message content into those contexts. The From field is perfectly
>> valid, however. Does that really mean that identifier alignment ca
>What sort of remedy would you suggest here? Off the top of my head, here
>are some suggestions:
>
>1) Evaluate all the domains you find, and if any of them have published
>DMARC policies, apply the strictest one ...
Given the anti-phishing goals of DMARC, I don't see how anything else
makes any
>A more general comment: reading the wiki and the discussions on this
>list, it get the impression that we seem to focus more on the issues
>related to the 'DKIM part of DMARC' then on issues related to the 'SPF
>part of DMARC'. Is my observation correct, do we tend to forget SPF here?
I agree
In article
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>> I'm not Doug, but Google unquestionably did that when AOL and Yahoo started
>> publishing p=reject
>
>Again, this is an assertion and where is the evidence for this?
Tech people at Google told me that's what they did.
R's,
John
_
of email are often incredibly problematic. Thanks to John
>Levine for quietly
>inserting this into the WG's wiki.
>
>I'll be trying to find.. volunteers... from various embedded communities to
>contribute to
>this page. Feel free to note your own experiences.
I stuck in a
>The discussion of interoperability between DMARC and MLMs has become opaque
>enough to
>warrant taking the time to document the learning. To make comparing and
>contrasting between
>MLMs possible, I think the WG needs a model --
Take a look at RFC 6377. It's not really a BCP, but it lays out
>> The typical reaction to the disruption they created was to translate their
>> p=reject into p=quarantine.
>
>Would you provide some proof of this assertion?
I'm not Doug, but Google unquestionably did that when AOL and Yahoo started
publishing p=reject.
R's,
John
_
>while some BBS's have evolved more mailing list type functionality "receive
>posts via email, respond to posts via email". The ones that started as MLM
>tend to use "from is author" and the ones that started as a BBS tend to use
>"from is mediator".
Having been there at the time, I'm fairly conf
>mail readers. The existing use of X-Original-From is an existence proof
>of [perceived] utility, despite the absence of widespread (any?) MUA
>display of this data.
Who uses X-Original-From ? This is a real question, I'm not aware of
anyone who does.
R's,
John
PS:
>and the creators of DMARC
>The opportunity for this WG would appear to be to spell out sensible
>practices for use in the two situations, and perhaps to spell out the
>trade-offs for deciding between the two, assuming that we are able to do
>so without devolving into further equine abuse. I'd suggest that
>specifying a
I've added an indirect mail flow page to the ASRG wiki. If you don't
have a password to log in and edit, write to me and I'll give you one.
>> >IMO, the place to record the inventory is the wiki. Mailing lists are
>> >not a good place to keep such records.
>> I would love to add it to the Wiki,
>I would certainly suggest a thing independently of DMARC (thus "both
>technically accurate and real-world-sensible") and, indeed, can't even
>claim credit for it: this has come up before in both the DKIM/ADSP
>discussion and in the origin of the term "authoring list". I am
>surprised to learn
In article
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>In Denmark we have a somewhat large (10K+ domains) anti-virus/spam provider
>breaking DKIM signatures.
>They break DKIM signatures on incoming email by adding a "Virus scanned by
>" line to the body of the email.
>
>Not sure how to fix this,
>2. Mailing lists; although the big ones seem to be rewriting the From
>(thanks).
Just for the record, the mailing lists I know that are rewriting the
From: line are not doing so because the change is in the interest of
their users, but because of the enormous market power of the mail
systems that
>Hmmm... I suppose we should also cite adding the mechanism into the
>DMARC spec, if there is a standard developed in time?
Considering what we're (not) doing in DBOUND, I wouldn't hold my breath.
> (Given the range of
>functionality suggestions already made for finding the OD, the question
>of h
>> An organizational domain is the 'base' name that is allocated from a
>> public registry; examples of registries include ".com" or ".co.uk".
>
>Both of those are fine with me.
That's fine with me, too, but be prepared for arguments from domains
like uk.com that sell subdomains underneath a dif
> The working group will seek to maintain
> the viability of stable domain-level identifiers in mail, and will
> document existing mail streams that do not conform to the DMARC
> model.
>
I'm not sure what this means. Can someone explain?
>> I'll bet a pretty goo
>2. "The working group will seek to maintain the viability of stable
>domain-level
>identifiers in mail.." This is a powerful statement. I take this to mean that
>the WG
>won't have to focus on the "Why" of stable domain-level identifiers in mail?
>If this
>is the case, I'm suddenly seeing the
>DMARC and traditional mailing lists don't play nice for two reasons: the
>subject is modified to add a prefix,
>which invalidates the DKIM signature, and the body is modified to add a
>footer, which again invalidates the DKIM
>signature.
It's more than that. Lists do all sorts of other stuff,
>I don't see how this can be considered out of scope without a viable
>alternative. The identification of the Administrative Domain is a
>normative requirement in DMARC, and if this problem is not solved, the
>specification will be stuck. Having tried and failed to solve this
>problem several years
>> 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
>> It is presumably permitted to check an external clock to find out what
>> time it is to validate the x= or t= tags. How come that's OK, but
>> checking the message for the presence of a signature with d=whatever isn't?
>
>That has not appeared (to me) to be the nature of what you have been
>esp
>> 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 supp
>The problem may be that we don't agree about what DKIM versions mean.
>Here's what I would like them to mean: ...
>c) Whenever we add new tags that require that the verifier understand them
>to get the right answer, we increment the version number.
Ned pointed out that we could add an indicato
>Question to the group: Does silent discard help? Or rather, do we have
>any indication that noisy "p=reject" does or can hurt?
ADSP had silent discard. It avoided the problem of people bouncing
off lists, but made the "where did my mail go" problem even worse.
DMARC has p=quarantine. In disc
>Playing around with ideas here. This one removes the "l=0" signature stuff
>and instead makes DKIM-Delegate into a more self-contained thing, which I
>believe was suggested (or at least inspired) by Stephen's comments. There
>is still the potential for abuse during the ephemeral relationship per
>Also, it's a dance to put more policy data into the DNS in any form. The
>"DNS people", as we appear to like to call them, don't like use of DNS to
>store policy data even though it's extremely convenient for us to do so.
>At a minimum, if we try to do that with TXT records again, we can expect a
> > [A DNS-based whitelist] does require u make a whitelist, ofc, but
> > other than inputing it into DNS, doesn't require u do anything else
> > with it,
>
>Inputting it into DNS is a *very* big deal, however. First, it's not
>at all clear that it scales to precisely the sites I (at least) care
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 mean
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 a
Here's the exact same proposal, except done with a new header
CDKIM-Signature rather than a DKIM version bump.
A new version of I-D, draft-levine-cdkim-00.txt
has been successfully submitted by John Levine and posted to the
IETF repository.
Name: draft-levine-cdkim
Revision:
R's,
John
-
A new version of I-D, draft-levine-dkim-conditional-00.txt
has been successfully submitted by John Levine and posted to the
IETF repository.
Name: draft-levine-dkim-conditional
Revision: 00
Title: D
>Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM
>failure is frequently not a
>sufficient basis for rejection.
I should hope not. The DKIM spec is crystal clear that an invalid
signature is equivalent to no signature.
R's,
John
_
> > Your plan, as I understand it, was that verifiers will ignore a
> > signature that is too weak. One might argue clients that accept weak
> > signatures are already broken, but in that case there are an awful lot
> > of broken clients, starting with spamassassin. (I just checked.)
>
>Spamassas
>I do not understand this predilection for trying to change the DKIM base
>engine. It doesn't need it.
Actually, I claim that a version bump is the approach least likely to
break existing clients.
>I also don't understand the construct of 'special handling', never mind
>not liking the idea of 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
>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 -- i
> > 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
>On Wed, Jun 11, 2014 at 7:15 AM, John Levine 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 igno
This looks like a cleaner version of my forwarding token proposal.
>> You're constraining it to use by a specific, very small set of domains,
>> and only for a limited time.
>
>Then again, let's note that this double-signed mail is going to show up
>at some receivers that don't know about DKIM-del
>Similarly in case of bypassing DMARC by wrapping the message, or a
>length limit on the DKIM signature, IWBNI the unauthenticated parts of
>the message were given a "nice UX" treatment semantically equivalent
>to displaying it in grey45 on grey50, adding a big warning in red
>explaining that From:
>It is mentioned in Section 6, but the mention there doesn't even say that
>it's the DMARC result that's supposed to be recorded. That bit at least
>needs to be fixed.
>
>Anyone else have a comment?
Recording stuff in A-R is fine. Advice about how MUAs should display
them is not. Considering th
In article <5393423a.2000...@gmail.com> you write:
>On 6/7/2014 6:38 PM, Stephen J. Turnbull wrote:
>> I don't know what the problem that prevented netnews from
>> obsoleting mailing lists is
>
>At base, netnews and mailing lists are entirely different kinds of human
>communication services. The c
Dave Crocker wrote:
>On 6/7/2014 4:37 PM, Franck Martin wrote:
>> Yahoo has been suggesting the ESPs use OAUTH, so the small business owner,
>> can authorize
>the ESP to post on its behalf via yahoo servers� Not sure if it is today
>possible, but there
>is a bunch of apps that has been granted
In article
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 for hosted mailing lists for small
entities. I was on a call
>I'm beginning to lean towards liking the "embedded message" solution that
>mailman has, though. In my testing, it works mostly fine in Gmail, though
>it assumes (and prefixes with) "forwarded message". YMail's handling isn't
>that pretty, however, as it ignores the headers of the embedded messag
>I'm beginning to lean towards liking the "embedded message" solution that
>mailman has, though. In my testing, it works mostly fine in Gmail, though
>it assumes (and prefixes with) "forwarded message". YMail's handling isn't
>that pretty, however, as it ignores the headers of the embedded messag
> 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
>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
>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 bucket
>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,
901 - 1000 of 1011 matches
Mail list logo
