> On Apr 6, 2016, at 11:24 AM, Binarus via Info-cyrus <info-cyrus@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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@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.
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.
You talk about rejecting using DKIM, but don’t publish a domain key yourself. What if one of your users needs to send messages to a server that has your attitude, but thinks that SPF is pointless?
DMARC indicates to the receiving server a policy that specifies the sending domain owner’s level of confidence in their own SPF and DKIM records. DMARC basically tells the receiver that the owner of the sending domain agrees that you should reject messages that don’t pass SPF or DKIM.
> 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?
It would lend legitimacy to rejected messages that have incorrect DK or SPF alignment. Again, publishing such a record would help others.
> 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.
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.
> [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.
>
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.
>> 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.
>
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.
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.)
Nobody (besides your employer) can require you to do anything other than what you’re doing, but it’s not okay to memorialize bad information in the archives of this list if we know better.
> 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.
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.
I think everyone generally deserves the results of their decisions. No one deserves spam, save possibly every lawyer.
>> 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.
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. 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.
It’s possible to reduce spam by 100% by just turning off the server, though the utility of that approach is suspect.
--
Stephen
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
