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

[Binarus]

On 06.04.2016 02:54, Stephen Ulmer wrote: 
> You make some good arguments, but then you say other things that make me think you’re not clueful. I think you’ll be more persuasive if you consider the following:

Indeed, I'm not clueful regarding DMARC. Regarding SPF, DKIM and SMTP in general, I am considering myself quite clueful.

> To be a good citizen, you should care about the possibility of others sending spam in your users’ names — we will *eventually* wind up with a reputation-based anti spam network of some kind, and you’ll want to have protected them from before its inception. Ergo, you should care at least a little about DMARC. It's one TXT record — in an environment where you can just reject whatever mail you want, clearly you’ve got the authority to implement such.

I am all times reading that people believe that SPF or DKIM can prevent spammers from sending messages in their names. As I have already stated multiple times, this is just wrong. Of course, every spammer can always send messages with an envelope-from or from of your_name at your_domain, regardless of SPF or DKIM records for your_domain. SPF and DKIM only help the *receiving* MTA to decide if the message is really coming from the pretended sender('s domain). DMARC does not change that.

Furthermore, I can't see much sense in DMARC (except the reporting protocols) at least for the following reasons:

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?

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?

[Note: Quarantining a message includes accepting it!]

Furthermore, I wouldn't respect a DMARC record which told me to quarantine a message because quarantining it means accepting it before, and this again would enable the sender to prove that our MTA has received the message and would force us to check the quarantined messages on a regular basis.

And, last but not least, we won't use a reputation based anti spam network because we don't need it. Our world is black and white:

- All messages from blacklisted domains are rejected.
- All messages which pass DKIM or SPF are accepted (even if they later turn out to be SPAM).
- All other messages are rejected (without blacklisting the respective domain, of course).
- If SPAM is sent by a domain (proven by SPF or DKIM), this domain becomes blacklisted until the domain owner calls us and explains what has happened.

Still not being clueful regarding DMARC, I didn't know that it also is just one TXT record - thanks for the hint. If it's really that easy, we will implement this, but only from the sender's viewpoint, i.e. we won't make our MTA check / use DMARC records.

> There are PLENTY of anti-spam measures “on the server side”. You could choose to use Spamassassin, and reject the most egregious messages (with whatever explanation you’d like). You could also use any number of RBLs. Greylisting has at least some positive effect. You might choose not to implement any of these for various reasons, but they certainly exist and can be effective.

This is all true, but why should we? Of course, we have thought about SpamAssassin and similar solutions. But our solution, as currently implemented, does not leave any uncertainty: There is one single clear criterion for blacklisting a domain (namely if it is proven that the domain has sent spam), and we are sure that the pretended sender of every rejected message gets a DSN, so we are on the safe side from the legal point of view.

Our solution has three downsides:

1) Before blacklisting a domain, SPAM mails from that domain get to our users.

2) Some big providers don't implement SPF or DKIM, so we are rejecting messages from these.

3) After having received SPAM from a big provider's domain, we usually blacklist this domain, thus preventing a large number of users from sending us messages.

We can happily live with these downsides, especially when comparing them to the downsides of other solutions (due to the nature of our company, we won't receive messages from the big freemailers anyway).
 
> If you are only checking for false-positives once a year, you deserve whatever the volume in which you are mired. 

I don't know what sort of job you have, but I can tell you that you are lucky if you can take the time for doing this on a daily (or weekly or monthly) basis (I usually have done it during Xmas holidays). Furthermore, are you god who can decide what we deserve? I think you have got something quite wrong: Nobody deserves any SPAM message.

> I have not seen you indicate how you address all of the legitimate messages you are rejecting because their senders don’t implement SPF or DKIM. Do you have good statistics to indicate how many fewer *ham* messages you’re delivering each day? That would be an excellent data point if it existed.

We address them by returning a DSN which contains a polite text explaining the problem and asking the sender if he could tell his administrator / provider about it. I don't have figures regarding the other clients, but at least in my case the number of ham messages which I did not receive due to our new policies is negligible. At least, (nearly) no more having trouble with SPAM (working time, dangers of phishing / viruses, legal aspects of unread messages) is more than worth "losing" a negligible number of ham messages.

Peace,

Binarus