[mailop] DMARC with broken DKIM (was: Re: DMARC p=quarantine pct=0)
On 04/09/2018 08:45 PM, Jesse Thompson wrote:> Kinda, yes. Anyone
running a non-compliant list server should look to
> how other list servers are making themselves compliant. Could be...
> 1) rewrite headers
> 2) not break DKIM
> 3) ARC?
> I don't want to be overly prescriptive (no one in academia likes to be
> told what to do) but rather to let people know that (a) change is coming
> and it isn't scary, and (b) here are some possible changes you can make
Slight topic change: We've seen email sent from email servers using
DMARC p=reject but with broken DKIM (basically relaying through sendgrid
but with some error in the DKIM DNS configuration, as far as I can
remember).
We handle an email forwarder that, usually, doesn't break DKIM, so DMARC
should be fine. Except when the source mail is DKIM-invalid and the only
thing that makes all the mail not to be rejected is SPF alignment, which
we cannot fix on our side.
What is there, as an email forwarder, that we could do to be compliant?
Currently our only guess is to rewrite headers when the email comes with
broken DKIM yet valid SPF, but even though it's OK for lists that's
unexpected from the user's point of view from forwarding services…
Or should we just reject these mails and tell the sender to do the
things properly? doesn't work well with the end users…
Sometimes I'm thinking DMARC should have enforced DKIM, and not allowed
to have only a match in {SPF, DKIM}, because it leads to issues like
broken-DKIM working-SPF domains not noticing things are wrong even
though they *are*…
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] DMARC with broken DKIM
On 04/10/2018 01:04 AM, Brandon Long wrote:
> We've also seen various banks and other large companies who seem to
> specifically only
> use SPF with DMARC, as a way of disallowing forwarding, I guess.
>
> With ARC, you can actually "pass" the SPF pass through the forwarder.
>
> Not that there's anywhere near wide enough acceptance of ARC to make
> that your default.
Hmm, I seem to remember even Google (who IIRC pushed for ARC, but you
know better than me) doesn't open ARC to third-party forwarders? Also,
ARC requires a relationship of trust between the forwarder and the
forwarded-to, if I remember correctly? So that couldn't reasonably work
for us, as we redirect to a few thousands different domains, so
something that requires explicit agreement with each forwarded-party
would likely never work.
> Rewriting or rejecting. I tend to favor rewriting, but arguments can be
> made both ways. Assuming the
> forwarding service is something set up by the receiver, than they almost
> certainly would prefer to
> get the mail.
>
> As for whether DMARC should have allowed SPF, there were several policy
> proposals based
> on DKIM directly that failed. DMARC added three things to those, From
> header alignment, reportting
> and SPF. Which of those made it more successful than the previous
> attempts, or was it just the parties
> involved in creating it, the timing, the need getting big enough... who
> knows.
Well, reporting and From header alignment make a lot of sense, I just
don't get why SPF. The aim of DMARC is to ensure a message originated
where it originated from, so what's the point in SPF when DKIM's
available? The only reason I could think of would be protection against
replay attacks, but that's taken care of by Message-Id and
de-duplication filters.
Well, anyway, that's wishful thinking on my part, unless there's a DMARC
v2 that disallows SPF-only and some major email provider drops support
for DMARC v1 in favor of v2 only there won't be any change, and that's
not really likely to happen any time soon, so…
> Brandon
>
> On Mon, Apr 9, 2018 at 3:35 PM Leo Gaspard via mailop <mailto:mailop@mailop.org>> wrote:
>
> On 04/09/2018 08:45 PM, Jesse Thompson wrote:> Kinda, yes. Anyone
> running a non-compliant list server should look to
> > how other list servers are making themselves compliant. Could be...
> > 1) rewrite headers
> > 2) not break DKIM
> > 3) ARC?
> > I don't want to be overly prescriptive (no one in academia likes to be
> > told what to do) but rather to let people know that (a) change is
> coming
> > and it isn't scary, and (b) here are some possible changes you can
> make
> Slight topic change: We've seen email sent from email servers using
> DMARC p=reject but with broken DKIM (basically relaying through sendgrid
> but with some error in the DKIM DNS configuration, as far as I can
> remember).
>
> We handle an email forwarder that, usually, doesn't break DKIM, so DMARC
> should be fine. Except when the source mail is DKIM-invalid and the only
> thing that makes all the mail not to be rejected is SPF alignment, which
> we cannot fix on our side.
>
> What is there, as an email forwarder, that we could do to be compliant?
> Currently our only guess is to rewrite headers when the email comes with
> broken DKIM yet valid SPF, but even though it's OK for lists that's
> unexpected from the user's point of view from forwarding services…
>
> Or should we just reject these mails and tell the sender to do the
> things properly? doesn't work well with the end users…
>
> Sometimes I'm thinking DMARC should have enforced DKIM, and not allowed
> to have only a match in {SPF, DKIM}, because it leads to issues like
> broken-DKIM working-SPF domains not noticing things are wrong even
> though they *are*…
>
> ___
> mailop mailing list
> mailop@mailop.org <mailto:mailop@mailop.org>
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
On 05/25/2018 12:14 PM, Rolf E. Sonneveld wrote: > Yes, dealing with exactly the same kind of problem(s). One of my > customers asks me to sign for the fact that mail is encrypted when > handling it. However, using standard MTA software, messages that are in > the queue waiting to get delivered, are unencrypted. Am I forced to use > disk encryption? Just for the record, OpenSMTPD supports queue encryption with the `queue encryption` option. I guess (hope?) other MTAs do support it too. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] The utility of spam folders
"Bill Cole" writes: > I know from doing it that limbo-free email can be done well enough > (minimal bad mail being delivered or good mail being rejected) that > paying users will come to prefer it over freemail-like service. That > service model lacks significant economies of scale (and arguably has > net diseconomies of scale,) but by the most objective metrics of value > it is a better service model than that of the behemoths. The current discussion about a mail failing DKIM-verification being rejected by gmail and unsubscribing most gmail customers from this very mailing list make me wonder whether limbo-free email is actually a good idea: rejection of the mail will likely trigger the mailing lists' automatic unsubscribing feature. Which means that if either the ML's antispam lets a spam through or one of the ML's legitimate email gets falsely spam-detected, then a rejection will happen and the user will likely get unsubscribed from the ML. Am I missing something that would prevent such a scenario from occuring? Cheers, Leo ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Laura Atkins via mailop writes: > For victims of listbombing, COI isn’t an answer. In fact, much of the problem > with listbombing is COI mail. > > How do you propose to address that issue? Captchas are a way to force the malicious subscriber to spend human or computer time breaking it (if captchas can be broken). As a consequence, it might make sense to just accept it is the case and require a javascript-generated proof of work before accepting the subscription. This way the amount of computer time required can be more easily modulated, and the human is not faced with a hard-to-answer captcha -- I don't know how you feel, but as a user I'd much rather have my computer spin for a few tens of seconds before sending the form (especially as it can happen at the same time as I fill it) than have to fill in a captcha. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Steve Atkins via mailop writes: >> On May 10, 2019, at 10:50 AM, Leo Gaspard via mailop >> wrote: >> Laura Atkins via mailop writes: >>> For victims of listbombing, COI isn’t an answer. In fact, much of the >>> problem with listbombing is COI mail. >>> >>> How do you propose to address that issue? >> >> Captchas are a way to force the malicious subscriber to spend human or >> computer time breaking it (if captchas can be broken). >> >> As a consequence, it might make sense to just accept it is the case and >> require a javascript-generated proof of work before accepting the >> subscription. >> >> This way the amount of computer time required can be more easily >> modulated, and the human is not faced with a hard-to-answer captcha -- I >> don't know how you feel, but as a user I'd much rather have my computer >> spin for a few tens of seconds before sending the form (especially as it >> can happen at the same time as I fill it) than have to fill in a >> captcha. > > Bad people have access to much more, and much cheaper, compute resource > than good people. > > There are other things wrong with your suggestion but that's > a simple thing to think about first. It also generalizes to many other > poorly thought through "just use proof of work to solve email problems!" > ramblings. I hope you didn't assume I was saying it's a good idea. I was *only* saying it was a better idea than captchas, as an answer to Laura's question. And I stand by this statement: the effect on bad people is approximately the same as the one captchas have (well… maybe a bit less efficient when the captcha is strong enough for requiring a captcha relaying attack? but I'm used to failing answering those captchas as a human too anyway, so might as well have a 10min proof of work…), and the effects on good people are much, much less painful than the ones captcha have. Basically, captchas are a POW for malicious actors, and a dice the user rolls for the normal user. When computers were unable to do basic OCR, they were a good idea. Nowadays, the user gets more pain than the malicious actors, for whom even 1/10 success rate is enough to get lots of forms through without questions. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Report as spam and mail forwarders: best practices?
Hello all, We handle an email forwarder. Recently, we have been having more and more issues with people reporting forwarded emails as spam, that end up (probably) deteriorating the reputation of our email servers. We have already set up: - an antispam, but some emails marked as spam are even to human eyes not obviously spams, and mostly depend on how the recipient feels about it - SRS - Addition of Delivered-To and X-Original-To headers - Forwarding the email to abuse@ or spam@ will help us feed it to our antispam Do you know of additional best practices we could do, to better help training our antispam as well as hopefully redirect at least some of the reputation loss to the actual sender of the email? Thank you, Leo Gaspard ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Report as spam and mail forwarders: best practices?
Michael Peddemors via mailop writes: > Since every email client in the world can check multiple mailboxes, ISPs > and Telco's are starting to simply turn off 'remote forwarding', it is > an option for you of course. Unfortunately, this is not really a reasonable course of action for us: most people still just use their ISP's webmail, which rarely supports checking multiple mailboxes and even if it did would require a significant amount of configuration by the end-user… we already have issues keeping up-to-date email addresses for all the users, as they often forget to notify us changes, so getting them all to regularly fetch emails from IMAP servers we'd setup sounds pretty much impossible. > Which is why you should consider the spam protection as an integral part > of the email service, and not simply a 'pre-filtering' system, as this > way cases of "one man's spam is another man's reading material".. > > Let the customer make the final choice.. eg 'Click Allow/Block Sender'. This sounds like a neat idea! however, there is an issue with it: adding these links would break DKIM, and so we would have to rewrite the From header for all emails… which sounds like a pretty bad UX downside. If only there were a way to add a DKIM-unsigned mime block to the email, that the UI would display as being obviously not-from-the-sender… it could solve this issue maybe. >> Do you know of additional best practices we could do, to better help >> training our antispam as well as hopefully redirect at least some of the >> reputation loss to the actual sender of the email? > > Never forward known spam ;) Well… if only it were that easy :p ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Report as spam and mail forwarders: best practices?
We have, and also sometimes click on “unsubscribe” on emails people mark as spam that get forwarded to us. This being said, maybe we missed a feedback loop? I have just checked and found [1]; we'll subscribe to the ones we missed that are listed there. [1] https://help.returnpath.com/hc/en-us/articles/220221448-List-of-all-available-complaint-feedback-loops-FBLs- Maybe one thing we should do, would be to automatically send an email to people who click the spam button (as defined by reception on abuse@) to tell them to instead forward the mail to spam@? but then it would come at the risk of actually generating emails that people would see as spam, so it doesn't sound that great… Russell Clemings via mailop writes: > Have you at least signed up for all the feedback loops you can find? That > seems to help with reputation and it also helps you track down and counsel > users who think the spam button is the same thing as the delete button. > > > > On Fri, Jun 19, 2020 at 9:16 AM Leo Gaspard via mailop > wrote: > >> Michael Peddemors via mailop writes: >> > Since every email client in the world can check multiple mailboxes, ISPs >> > and Telco's are starting to simply turn off 'remote forwarding', it is >> > an option for you of course. >> >> Unfortunately, this is not really a reasonable course of action for us: >> most people still just use their ISP's webmail, which rarely supports >> checking multiple mailboxes and even if it did would require a >> significant amount of configuration by the end-user… we already have >> issues keeping up-to-date email addresses for all the users, as they >> often forget to notify us changes, so getting them all to regularly >> fetch emails from IMAP servers we'd setup sounds pretty much impossible. >> >> > Which is why you should consider the spam protection as an integral part >> > of the email service, and not simply a 'pre-filtering' system, as this >> > way cases of "one man's spam is another man's reading material".. >> > >> > Let the customer make the final choice.. eg 'Click Allow/Block Sender'. >> >> This sounds like a neat idea! however, there is an issue with it: adding >> these links would break DKIM, and so we would have to rewrite the From >> header for all emails… which sounds like a pretty bad UX downside. If >> only there were a way to add a DKIM-unsigned mime block to the email, >> that the UI would display as being obviously not-from-the-sender… it >> could solve this issue maybe. >> >> >> Do you know of additional best practices we could do, to better help >> >> training our antispam as well as hopefully redirect at least some of the >> >> reputation loss to the actual sender of the email? >> > >> > Never forward known spam ;) >> >> Well… if only it were that easy :p >> >> ___ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > > > -- > === > Russell Clemings > > === > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Report as spam and mail forwarders: best practices?
Atro Tossavainen via mailop writes: >> We handle an email forwarder. Recently, we have been having more and >> more issues with people reporting forwarded emails as spam, that end up >> (probably) deteriorating the reputation of our email servers. > > You could ask the good folks at iki.fi for tips. They've only been doing > this for 25 years. Will do, thank you! ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
