Request: Please sign this list's messages via DKIM or SPF

[Binarus]

On 06.04.2016 18:54, Stephen Ulmer wrote:
 
> You ignored my point about being a good citizen. I’m talking about what you PUBLISH, how it is useful to others, and how it will eventually lend protection to your users reputations as the number of DMARC implementations increases.

In my last post, I wrote that we probably will implement DMARC from the sender's point of view, mainly due to your hint how easy that is.
 
> You talk about rejecting using DKIM, but don’t publish a domain key yourself.

This is a great misunderstanding. Of course, we are publishing our DKIM key(s), are signing all messages we send by DKIM, and have published an SPF record. I just have said that we don't use DMARC yet. Please note that DKIM, SPF and DMARC are three things which are tied together very loosely. Basically, SPF and DKIM exist on their own and are completely independent from each other, while DMARC uses both of them.

>> 1) If an administrator is not able to add an SPF record to his DNS (which is also one TXT record with a syntax which can't be easier), he probably will as well not be able to add a DMARC record. So, from our point of view, since we already accept all messages which pass SPF, what would be good in additionally checking / respecting the DMARC record?
 
> It would lend legitimacy to rejected messages that have incorrect DK or SPF alignment [...]

And this is exactly the thing which should *not* be done. Why on earth should we help spammers with delivering their messages by letting a DNS server say: "Hi guys, mail messages pretending to be from our domain are likely to be actually sent by spammers, but please accept them all nevertheless because our admin doesn't have 5 minutes to fix the broken SPF record"?

In other words: If I ever would see a server / domain which is configured like that, this wouldn't lend legitimacy to it; instead, I would blacklist it immediately for helping the spammers. I don't assume that I will have do do this because we won't use DMARC at the receiving side and so I won't get noticed about such heavily broken configurations, though.

>> 2) I definitely won't respect DMARC records which tell me to accept messages although they don't pass SPF or DKIM checks. Setting up such DMARC policy (until I have heavily misunderstood something) re-enables SPAM: When such a record exists for a domain, every spammer could send messages in the name of that domain, the receiving MTAs then would look up the DMARC record of that domain and would accept the message since the DMARC policy says that the messages should be accepted regardless of missing or wrong SPF / DKIM. Are they completely crazy?

> It only "re-enables" spam if you think that the lack of SPF and DKIM records are indicators that the originating domain does not send legitimate messages.

No. It helps spammers get their messages into the receiving MTA in every case. If a spammer fakes the sender of a message and thus DKIM and SPF don't pass, but then the receiving MTA accepts the message due to DMARC records, the spammers have won. That does not make any sense in my eyes.

> Some administrators who have responsibility for many other people’s messages like to actually test things and observe the behavior. There are non-reject options in DMARC so those admins can get reports about activity in their name without disrupting an existing system. It is a polite request for diagnostic data from other system owners. I don’t believe that anyone leaves p=none in place for forever (though I could just be wrong about that). You might be surprised by getting some of those reports.

I agree, and I also think that DMARC's reporting protocols are a good thing. I don't want to keep anybody from using DMARC; I just said that we won't use it at the receiving side for the reasons I have mentioned (we are a very small company and thus don't need to run long tests before doing such things).
  
> My point about reputation-based systems is not about what you consume, which seems to be all you care about. You can publish DMARC records and help other administrators know what email from YOUR domain is legitimate.

Thanks to your hint about how easy that is, we'll probably do this very fast.
  
> Here is where I was talking about what you accept. Rejecting a message based on its spam score does not leave any uncertainty. The acceptance status of the message is by definition no more or less clear than anything you are doing now.

I don't think so. We have our MTA deliver all messages to our users if they pass SPF or DKIM (except from blacklisted domains), even if they are SPAM. This means that it is a human who finally decides if a message is SPAM and if the respective domain should be blacklisted. In contrast, SpamAssassin returns some sort of spam score which is computed according to some very intelligent magic, to long, long training (hopefully) and to all sorts of other rules of arbitrary complexity. If you rely on that, you again get into the problem that you have to check you junk folder regularly.

So the different approaches are (a) manually blacklisting domains which have been proven to send spam (done by humans, our approach) versus automatic computing some spam score according to sophisticated rules and relying on that in further processing the message (done by software, SpamAssassin's approach).

> You made an assertion that there was nothing else you could do on the server aside from your current approach, which is just not the case. The claim made to bolster this argument is technically untrue. For all I know you might have been unaware that you can run SpamAssassin as a filter in the MTA. (There are a surprising number of mail administrators that know literally nothing about how messages get moved around.)

I know about that. But I also know that you need a lot of expertise to make it work the right way, and you can't get around the obligation to check your spam folders on a regular basis if you process your messages according to the spam score. Amusing: AFAIK, you can include SPF and DKIM tests into SpamAssassin's rules ...
 
> You have missed my point. If you get SPAM at a rate of x/day, then waiting to look when you have 365x to wade through is your own decision — so don’t whine about it. You could easily decide to look at 7x, or 28x, or whatever. You could look when you get to 1000, however long that takes. My point is that you make the decision about when to process your false positives, and the number of messages you must consider is a direct result of your own scheduling.

It's not really my decision. There is just no time for it during normal working days. Or, in other words, during working days, my time is too expensive to waste it that way.
 
> I don’t think you actually know how many legitimate messages you are rejecting, because if you could find/count them you would just accept them.

We've got an idea about that since there are the subject, envelope-froms and Froms, and the envelope-tos and Tos in the server's log for all messages (rejected or accepted).

> I also don’t know what kind of business your users conduct, so I don’t know if there is a large opportunity cost associated with rejecting a legitimate message. The policy you promote may work very well for you, but I would not consider it responsible for the vast majority of mail administrators.

I agree. It's just an approach which works great for us. At least as long as the big freemail providers don't implement SPF or DKIM the right way, our policy will not be an option for most other companies, let alone private people. Nevertheless we are hoping that more and more small companies will employ more rigorous policies in the future. That seems to be the only way to force the big providers to use those technologies.
 
> It’s possible to reduce spam by 100% by just turning off the server, though the utility of that approach is suspect.

Agreed.

And finally:

I am really hoping that the discussion about the sense and nonsense of SPF, DKIM and DMARC stops now.

I am assuming that we all agree that setting up an SPF or DKIM record for lists.cmu.edu and signing the messages won't harm anybody and on the other side would make life easier at least for a few people who are minded like us.

If the administrator is willing to setup such technologies and gets an OK from his management, we will be grateful. If not, we will find a way around the problem at our side.

In my first post, I probably should just have asked just for what I proposed, without giving a reason for it. On the other hand, I probably should give reasons when asking somebody to do something for me ...

Regards,

Binarus