On 11/22/19 6:25 AM, Jaroslaw Rafa wrote:
> Dnia 22.11.2019 o godz. 10:45:42 Wesley Peng pisze:
>> So mailing list makes DKIM or SPF failed?
>>
>> Thank you for your helps.
> My opinion is that the actual problem is that people who invented SPF and/or
> DMARC had wrong assumptions about how email works/should work.
>
> They assumed email is a straight and simple one-to-one communication like
> HTTP. If you send a mail from user1@xxx to user2@yyy, it goes straight from
> sending server for domain xxx to receiving server for domain yyy. So the
> receiving server can check if the email is coming from a "valid",
> "authorized" server for domain xxx (despite the fact that there isn't - and
> never was - such thing as "valid sending server" for any domain).
>
> This concept puts mailing lists, email forwarding and similar things
> completely out of scope. I would dare to say that these things simply did not
> exist for inventors of SPF/DMARC. That means, they obviously knew these
> things exist, but assumed they are completely unimportant and shouldn't (in
> their approach) be used.
>
> Big email providers started adopting SPF/DMARC etc. also without much
> thinking about these seemingly "unimportant" use cases, and then suddenly it
> turned out that we have quite a problem.
>
> You may disagree of course, but that's just how I see it. There is a quite
> old article about why SPF is wrong, but in my opinion this article didn't
> date a bit: http://david.woodhou.se/why-not-spf.html

Base SPF works through a traditional forwarder, because the base rules
for SPF allow the message to pass based on the domain of the Sender:
header, not just the From:. A proper forwarder will add a Sender: header
for itself, to indicate that while it was not the originator of the
message, it was the last one to send it. DMARC changes the rules for
SPF, and says that the message must align with the From: header, based
on the idea that most mail readers don't show you that sender does not
equal from.

SPF works just fine as designed, because it was designed as a HELPER for
receivers, not intending to be an all encompassing solution. If I, the
receiver of the message see that the message passed SPF, AND I trust the
domain that sent the message, then I can be fairly sure that the message
is legitimate. If there is a problem with the message, because I trust
the domain, I feel I can report the issue and it will be dealt with. SPF
is designed to help with 'white-listing'. SPF helps fight spam, as I can
white list the major mail agents that do a good job filtering spam, and
then have more bandwidth to look at those for sources I don't know.

DMARC adds nothing to that ability. Anyone can create a domain with a
strict DMARC policy and send spam from it. Just passing DMARC means
nothing in regards to the spamyness of a message. What DMARC is designed
to fight is forgeries. If you setup DMARC for your domain, then people
can trust that a message that says it is from you is from you (it still
could be spam though). The 'cost' of using DMARC is that you limit what
users of that domain can do, as they can't use external re-mailers that
don't follow very specific guidelines. This works for domains that deal
with transactional emails, where forgeries can be important, it doesn't
work for more casual usage.

I would actually say that an email provider using strict DMARC is
actually a sign of a email provider with a problem. I have heard that
the reason that Yahoo at least adopted it was that they had so many
security breaches that leaked out their users address books, that a very
real problem was yahoo members getting emails claiming to be from
friends that were actually attack vectors, that they couldn't keep up
with other measures to try and block it. The adoption of DMARC for a
general email provider is basically an acknowledgement that they have
problems maintaining a safe and secure email system. IF they advertise
it as a feature, and explain what it means you can't do, then maybe it
isn't, but if they don't inform you that they are not suitable for many
mailing lists and the like, then likely THEY are the one with a problem.

-- 
Richard Damon

Reply via email to