Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles
2021-05-25 16:55:25
John Levine writes:
It appears that Sam Varshavchik <mrsam(_at_)courier-mta(_dot_)com> said:
>I should clarify this. I see that occasionally. But when it does, I seem to
>always end up moving my goalposts, and conclude that the mail provider
>itself is rogue, and made a business decision to go into the business of
>providing spam outsourcing services, with some non-spam mail services on the
>side. So I treat it as a bad mail source.
You and I do not run large mail systems. The bigger you are, the less
latitude
you have to punish senders (even places like Sendgrid that deserve it) if it
means also losing the real mail they send. On my small system I have
elaborate
rules to post-filter Sendgrid's mail because there is useful stuff in with
the crud
and my users are sad if it disappears.
And that's why Sendgrid – and everyone else in their position – has no
incentive to clean up their act. Why should they, when most recipients on
the other side of the earth are willing to expend their effort to accomodate
Sendgrid – or anyone else in their position?
It used to be that they would just segregate their dirty mail from their
clean mail on different IP addresses, and that was their preferred solution:
go ahead, feel free to just block those guys over there, they'll continue to
pay us anyway.
Now, they don't even have to do that. They can simply say: hey, here's the
sender, feel free to sort the senders yourself. The burden on you to go
through the hassle of identifying the sender, and filtering them out.
I think what's happening, in the grand scheme of things, is the elimination
of small to medium E-mail providers. E-mail is being split between the
extreme low end: individuals running their own E-mail for either themselves
or their organization. They don't realy on E-mail, don't consider it
critical, and can afford to brutally filter their incoming E-mail. They
don't mind an occasional loss of an attempted personal contact from the
public. They just want to avoid having their mailbox getting filled with
junk every day.
And then we have the large E-mail providers. They can afford to invest
resources in implementing sophisticated, score-based mail filtering
techniques, employing DKIM, DMARC, and paying for a non-free blacklist.
A small-to-medium E-mail provider just won't have the resources to compete,
I believe, over the long term. What we're talking about here, will /not/ be
sufficient to clean their incoming E-mail, by itself. They'll still have to
constantly waste time constantly adjusting their filters and figure out what
to do with each new source of mail they haven't seen before.
>Eh, no. A large majority of user-facing mail clients are now hiding the
>sending mail address, and showing only the name, up front.
>
>From: "Paypal Customer Service" <kjsdfjklk(_at_)934iowero(_dot_)us>
Yeah, we know. But large providers tell me that DMARC still blocks a great
deal of phish that uses the target's actual domain name.
So does SPF, actually.
May 25 07:10:29 shorty courieresmtpd[28905]: error,relay=::ffff:
185.222.57.81,port=56202,from=<admin(_at_)courier-mta(_dot_)com>: 517 SPF fail courier-
mta.com: Address does not pass the Sender Policy Framework
May 25 07:50:58 shorty courieresmtpd[29001]: error,relay=::ffff:
195.140.213.254,port=54000,from=<raviadappa(_at_)bflhydro(_dot_)com>: 517 SPF fail
bflhydro.com: Address does not pass the Sender Policy Framework
May 25 08:57:31 shorty courieresmtpd[29918]: error,relay=::ffff:
36.92.9.83,port=7329,from=<info(_at_)lee(_dot_)org>: 517 SPF fail info(_at_)lee(_dot_)org: Address
does not pass the Sender Policy Framework
SPF is heck of a lot easier to implement.
And, thinking about this more: if something will fail a DMARC check, it's
almost a certainty that it'll fail an SPF check too. Chances are very good
that a domain that uses DMARC will also have an SPF record.
>Most people will see "Paypal Customer Service". Valid domain signature for
>934iowero.us, and straight it goes into your Inbox.
You're making the same mistake again. DMARC is not a whitelist. If
I didn't say that it was.
something is
DMARC aligned, all that means is that it was really sent by the domain in
the From:
header.
Right, but my point was DMARC will verify 934iowero.us, and the recipient
sees that the mail is from "Paypal Customer Service".
And if 934iowero.us is a brand new domain, with no reputation, then what?
You still apply reputaiton and other spam filters to it. It's not
a FUSSP.
And if it's a brand new domain and has no reputation?
So, what's the starting point here. What are we going to do with new domains
that validate in DMARC/DKIM, but have no reputation.
A) Vote them down. This winds up with large E-mail providers keeping
everyone off their turf. You have poor deliverability with a new domain,
unless you pay the danegold to big E-mail providers to send from their
infrastructure.
B) Do not vote them down. Factor in bad reputation only. Do not mark down in
absence of no reputation. This winds up with cheap domain recycling. Spam
the crap out of everyone using a new domain, until its reputation sinks.
Then switch to the next throwaway domain.
My point is: the domain-based reputation approach is being pushed by large
email providers because they don't want to terminate their paying customers,
who are paying them for the privilege of sending spam. These large email
providers would much rather prefer to do nothing more than an absolute
minimum amount of work to merely identify who is sending mail from them.
Then they can wash their hands, proclaim that their job is done; and it is
up to you to block their spambags, if you wish. You do all the work of
figuring out each domain's reputation.
Now, in that scenario, I'll agree, domain authentication would be very
useful for them. But only for them, and nobody else, except for those that
are willing to expend their own resources to filter the spam sources that
they should not have to filter in the first place.
And as long as this situation is acceptable by everyone, I don't see the
situation changing, since the situation is acceptable to everyone.
pgpfhCrkqkZeG.pgp
Description: PGP signature
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-smtp] Email explained from first principles, (continued)
- Re: [ietf-smtp] Email explained from first principles, Bron Gondwana
- Re: [ietf-smtp] Email explained from first principles, Alessandro Vesely
- Re: [ietf-smtp] Email explained from first principles, Kaspar Etter
- Re: [ietf-smtp] Email explained from first principles, Peter J. Holzer
- Re: [ietf-smtp] Email explained from first principles, John Levine
- Re: [ietf-smtp] Email explained from first principles, Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, John Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, John Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles,
Sam Varshavchik <=
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, John Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles, Nathaniel Borenstein
|
|
|