Re: [dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)
On 31/05/18 10:28, Richard via dmarc-discuss wrote: Date: Thursday, May 31, 2018 09:26:38 +0800 From: Roland Turner via dmarc-discuss Sending failure reports to strangers appears unjustifiable under GDPR. A currently common case where reports are going where they shouldn't is with mailing lists. If a list (that doesn't do rewrites) receives a message purportedly from say yahoo (which is set to p=reject), mail to every list member whose ESP enforces dmarc will cause a bounce/reject potentially causing a failure report to be sent. These list members have no relationship with yahoo, save that they are on a list that someone sent to using a yahoo address, and have no control over the list or ESP configuration. I can't think of a legitimate reason for yahoo to get these reports. Ongoing visibility of the impact of their p=reject decision seems reasonable, although that could readily be obtained from aggregate reports (and indeed more accurately, as more organisations send them). Interdicting phishing is not relevant (where it might be if the address were @paypal.com). Even understanding the mechanism of selected failures seems a fairly weak interest, and one that could be better pursued with private channels rather than ruf=. Interesting. - Roland ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)
> Date: Thursday, May 31, 2018 09:26:38 +0800
> From: Roland Turner via dmarc-discuss
>
> On 31/05/18 04:51, Jonathan Kamens via dmarc-discuss wrote:
>
>> On 5/30/18 4:22 PM, John Levine wrote:
2) The people receiving the failure reports aren't "total
strangers." They are either (a) the same people who run the
email infrastructure (if failure reports are handled
internally), who are presumably authorized to look at email
headers while troubleshooting issues, or (b) third-party data
processors (to use the GDPR terminology), which are permitted as
long as how they are using the data is disclosed to users.
>>>
>>> They're sent to whoever some ruf= tag points to. I get all the
>>> failure reports for any message with one of my domains on the
>>> From: line, even if if was forged or a typo or a configuration
>>> error and nobody related to me sent it. Sounds like total
>>> strangers to me.
>>
>> I don't think you can be held responsible if a "total stranger's"
>> email ends up in your inbox because they put your domain in the
>> From line of the email without your authorization. Furthermore,
>> of the cases you mentioned ("forged", "typo", "configuration
>> error"), I don't think anything but "forged" happens with
>> sufficient frequency to be worth your concern or the concern of
>> the European Union's member states' Data Protection Authorities.
>>
>
> This confuses two different "total strangers" cases:
>
> * One is the case where a message ended up somewhere unexpected
> because someone mistyped an email address (whether in a
> message or in a DMARC DNS record).
> * One is where an email receiver is blindly sending failure
> reports to organisations unknown to them.
>
> The former is fine as it stands, so long as the parties involved
> take responsible action with the resulting disclosures (deletion by
> the party who unexpectedly received the data - because continued
> processing, including retention, has no lawful basis - and
> correction of the error by the party who misconfigured a mail
> client, mistyped an address book entry, or mistyped a DMARC DNS
> record).
>
> The latter is the important question. Sending failure reports to
> strangers appears unjustifiable under GDPR.
>
> - Roland
>
A currently common case where reports are going where they shouldn't
is with mailing lists. If a list (that doesn't do rewrites) receives
a message purportedly from say yahoo (which is set to p=reject), mail
to every list member whose ESP enforces dmarc will cause a
bounce/reject potentially causing a failure report to be sent. These
list members have no relationship with yahoo, save that they are on a
list that someone sent to using a yahoo address, and have no control
over the list or ESP configuration. I can't think of a legitimate
reason for yahoo to get these reports.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
[dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)
On 31/05/18 04:51, Jonathan Kamens via dmarc-discuss wrote:
On 5/30/18 4:22 PM, John Levine wrote:
2) The people receiving the failure reports aren't "total strangers."
They are either (a) the same people who run the email infrastructure (if
failure reports are handled internally), who are presumably authorized
to look at email headers while troubleshooting issues, or (b)
third-party data processors (to use the GDPR terminology), which are
permitted as long as how they are using the data is disclosed to users.
They're sent to whoever some ruf= tag points to. I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it. Sounds like total strangers to me.
I don't think you can be held responsible if a "total stranger's"
email ends up in your inbox because they put your domain in the From
line of the email without your authorization. Furthermore, of the
cases you mentioned ("forged", "typo", "configuration error"), I don't
think anything but "forged" happens with sufficient frequency to be
worth your concern or the concern of the European Union's member
states' Data Protection Authorities.
This confuses two different "total strangers" cases:
* One is the case where a message ended up somewhere unexpected
because someone mistyped an email address (whether in a message or
in a DMARC DNS record).
* One is where an email receiver is blindly sending failure reports to
organisations unknown to them.
The former is fine as it stands, so long as the parties involved take
responsible action with the resulting disclosures (deletion by the party
who unexpectedly received the data - because continued processing,
including retention, has no lawful basis - and correction of the error
by the party who misconfigured a mail client, mistyped an address book
entry, or mistyped a DMARC DNS record).
The latter is the important question. Sending failure reports to
strangers appears unjustifiable under GDPR.
- Roland
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
[dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)
On 31/05/18 02:01, Jonathan Kamens via dmarc-discuss wrote: Two comments: 1) Most of the failure reports I've seen haven't included the message body, they've only included the headers. So the exposure is limited. I assume limiting the exposure is the whole reason why the reports don't include message bodies. True, however this seems like a peculiar position. Once you've acknowledged that limiting exposure is important, aggregate reports seem like a more appropriate tool. Note that there is a compelling reason for providing message bodies, arguably the reason for specifying the failure reporting mechanism in the first place, and that's identifying phishing sites to focus deactivation efforts on. Doing this without an NDA would appear problematic. 2) The people receiving the failure reports aren't "total strangers." They are either (a) the same people who run the email infrastructure (if failure reports are handled internally), who are presumably authorized to look at email headers while troubleshooting issues, or No. They are the people who run some other infrastructure. In the "volunteering failure reports without an NDA" case, they are strangers. (b) third-party data processors (to use the GDPR terminology), which are permitted as long as how they are using the data is disclosed to users. I think you're describing intermediaries with whom domain registrants contract to process their DMARC reports. These people are also strangers to the receivers who are sending the reports, unless they have separate agreements with those same intermediaries (most do, at least in the US and EU). Whether or not that they are Data Processors would depend upon the details of those agreements. I've never read one. There /could be/ a GDPR issue if failure reports are sent to a third-party processor /and/ that isn't disclosed to the user, but it isn't /ipso facto/ a GDPR issue to use a third-party processor to manage failure reports. No. Contracting Processors does not require disclosure to Data Subjects; instead contractual arrangements between Controller and Processor to maintain the Data Subject rights and other obligations are required. You're thinking about disclosure to other Controllers. - Roland ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
[dmarc-discuss] RUF and GDPR (Re: RUA vs RUF reports)
On 30/05/18 22:56, Richard via dmarc-discuss wrote: I realize that enforcement of GDPR is still a work in progress, but: > Failure reports send copies of your users' > mail to total strangers. would seem to run directly against its intent. I hadn't thought to perform this analysis: * Consent is out, unless you really want to (a) solicit voluntary consent from all of your users and (b) turn off failure reporting for those users who have yet to consent, or who have withdrawn consent.[1] * Necessity for the performance of a contract with the data subject would not withstand scrutiny. (Most mail services today are capable of operating without this; it's therefore provably not necessary.) * Controller's legal obligations are not relevant. * Data subject's vital interests are not relevant. * Public interest/official authority are not relevant.[2] * This leaves legitimate interests of the controller or a third party. In the legitimate interests case: 1. The interest must be identified. In this case I'd suggest something along the lines of improving the ability of the controller (and mail-server operators generally) to distinguish legitimate email from impersonation by helping domain registrants take action to (a) correct configuration errors in legitimate email and (b) shut down impersonation, by voluntarily sending copies of messages to the party apparently nominated by the registrant of the domain. 2. The means must be necessary (least invasive approach possible). As for necessity for the performance of a contract, I'd suggest that this is demonstrably not true. The vast majority of DMARC's protection with respect to failure reports can be achieved (and as being achieved) by failure reports provided under NDA and by aggregate reports. It would be necessary to demonstrate that the added value of the volunteering failure reports to strangers was material. 3. A balancing test must be performed (interests of the controller and third parties vs. rights of the data subject). In particular, this looks at what protections are in place. I'd suggest that, at a minimum, this would call for data transfer agreements with enforceable NDA terms and data minimisation. In the latter case, if it is possible to perform substantially the same processing on anonymous data (e.g. the aggregate reports), then skipping that measure would be hard to defend. More broadly, any situation in which controllers are automatically disclosing personal data to other controllers who are strangers to them would be extraordinarily difficult to justify under legitimate interests. Note that this is not the same situation as sending an email message at the request of a user, that's necessity for the performance of a contract. I'd suggest that automatic sending of failure reports to strangers would be very difficult to justify under GDPR. - Roland 1: There is a lot of confusion about this. Consent in GDPR terms (6(1)(a) and 7) means something quite different to consent in its contract- or common-law senses. In particular, if some other thing that the data subject cares about is conditioned upon that consent, or if the consent can't be withdrawn without the loss of some other thing that the data subject cares about, then it's not freely given and therefore - per the snappy little sentence at the end of 7(2) - didn't happen. This is not to say that the processing in question can't be lawful, only that consent can't be the legal basis. There are five other legal bases to explore... 2: Note that this is not a DIY thing; the interest/authority in question must be laid out in legislation. ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] RUA vs RUF reports
In article you write: >I don't think you can be held responsible if a "total stranger's" email >ends up in your inbox because they put your domain in the From line of >the email without your authorization. ... Maybe. I gather there's all sorts of cases where it is not clear how the operator of a domain relates to people with mail in that domain or in that subdomain. For example, I expect that university faculty or company CEOs might not be thrilled that random low level IT people were getting copies of their mail just because it happened to be forwarded in a mildly funky way. R's, John ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] General DMARC weakness - personal forwarding
On 31/05/18 02:31, Alessandro Vesely via dmarc-discuss wrote: On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote: On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote: [...] which includes pretty much all mail sites. The latter is *not* a slow-moving data set. It grows steadily. Steady growth *is* slow movement. Uh? I run a tiny mail site and get about 1.6 new domains per hour. It is much slower than light, but still too fast for an embedded list... Any global figure, anywhere? Too fast for an embedded list certainly. As I said, "forwarding mail-servers more generally would then be an obvious refinement", but also "Even the complete set of honestly operated mail-servers in the world - whether forwarding or not - is changing at a rate that is still orders of magnitude lower than the rate of change of IP addresses used for abuse, consequently collecting, distributing, and using this data would be relatively straightforward." I took it as self-evident that I was describing a transition from an embedded list to a reputation data feed. You would presumably not attempt to list all of the IP addresses used for abuse in an embedded list? 1: Granted, the list becomes a priority list for compromise attempts, much as happened with ESPs several years ago, but sudden spikes in volume can be treated as suspicious anyway, so the benefit in compromising a small forwarder is limited. Spamtraps will also work well, as usual. However, no spam indicator implies that the upstream ARC chain is faked. In theory, for example, ARC would allow me to switch to forward-before-filter (maybe CPU happened to cost me more than bandwidth, say.) In that case, you would tend to classify me as a spammer and possibly suspect that my keys were compromised. How to maintain the list remains unclear. You've lost me: * If you're forwarding unfiltered email to receivers who are able to make good use of ARC information, and assuming that they still trust you, then there is no problem here: you just have lousy filters. * If you're forwarding to people for whom either of those things is false, then you're shooting yourself in the foot. Don't be a bad neighbour: filter to the best of your ability, but don't sweat the rest. Your neighbours are most unlikely to appreciate your dumping cost onto them if you do otherwise. 100% agreed. The example —admittedly somewhat stretched— was meant to highlight the difficulty of substantiating statements like "I trust these guys not to lie in ARC signing/sealing". This is the bit where I'm not following you. Failing to provide neighbourly attention to the stream of mail coming out of your mail-server and failure to accurately ARC sign appear to be orthogonal concerns. (They might be loosely correlated to your level of diligence certainly, but are not otherwise causally related.) - Roland ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] RUA vs RUF reports
Can you elaborate on how typosquatting is relevant to this? I'm confused.
If one of your users sends email /to/ a typosquatted domain, and you've
DKIM'd the email properly on the way out, then you're not going to get
failure reports because the email does, in fact, pass DMARC.
If someone sends email /from/ a typosquatted domain, then you're not
going to get failure reports because it's not your domain in the From line.
I'm just... confused. I don't understand what scenario you are implying.
Can you clarify for me?
Thanks,
Jonathan Kamens
On 5/30/18 5:17 PM, Elizabeth Zwicky wrote:
It might be that you are correct about GDPR, but this has been a
concern well before the GDPR, and whether or not it concerns the Data
Protection Authorities, it concerns our privacy lawyers. Typosquatting
is, after all, a thing.
Elizabeth
*
*
*Elizabeth Zwicky*
Mail Abuse Distinguished Engineer
My oath: 濾 ☕️
On Wednesday, May 30, 2018, 2:02:45 PM PDT, Jonathan Kamens via
dmarc-discuss wrote:
On 5/30/18 4:22 PM, John Levine wrote:
2) The people receiving the failure reports aren't "total strangers."
They are either (a) the same people who run the email infrastructure (if
failure reports are handled internally), who are presumably authorized
to look at email headers while troubleshooting issues, or (b)
third-party data processors (to use the GDPR terminology), which are
permitted as long as how they are using the data is disclosed to users.
They're sent to whoever some ruf= tag points to. I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it. Sounds like total strangers to me.
I don't think you can be held responsible if a "total stranger's"
email ends up in your inbox because they put your domain in the From
line of the email without your authorization. Furthermore, of the
cases you mentioned ("forged", "typo", "configuration error"), I don't
think anything but "forged" happens with sufficient frequency to be
worth your concern or the concern of the European Union's member
states' Data Protection Authorities.
Jonathan Kamens
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note
Well terms (http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] RUA vs RUF reports
On 5/30/18 4:22 PM, John Levine wrote:
2) The people receiving the failure reports aren't "total strangers."
They are either (a) the same people who run the email infrastructure (if
failure reports are handled internally), who are presumably authorized
to look at email headers while troubleshooting issues, or (b)
third-party data processors (to use the GDPR terminology), which are
permitted as long as how they are using the data is disclosed to users.
They're sent to whoever some ruf= tag points to. I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it. Sounds like total strangers to me.
I don't think you can be held responsible if a "total stranger's" email
ends up in your inbox because they put your domain in the From line of
the email without your authorization. Furthermore, of the cases you
mentioned ("forged", "typo", "configuration error"), I don't think
anything but "forged" happens with sufficient frequency to be worth your
concern or the concern of the European Union's member states' Data
Protection Authorities.
Jonathan Kamens
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] RUA vs RUF reports
In article you write: >1) Most of the failure reports I've seen haven't included the message >body, they've only included the headers. Depends who you get them from. The ones from Netease are just the headers, the ones from Linkedin give you the whole message. >2) The people receiving the failure reports aren't "total strangers." >They are either (a) the same people who run the email infrastructure (if >failure reports are handled internally), who are presumably authorized >to look at email headers while troubleshooting issues, or (b) >third-party data processors (to use the GDPR terminology), which are >permitted as long as how they are using the data is disclosed to users. They're sent to whoever some ruf= tag points to. I get all the failure reports for any message with one of my domains on the From: line, even if if was forged or a typo or a configuration error and nobody related to me sent it. Sounds like total strangers to me. R's, John ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] General DMARC weakness - personal forwarding
On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote: > On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote: >> [...] which includes pretty much all mail sites. The latter is *not* a >> slow-moving data set. It grows steadily. > > Steady growth *is* slow movement. Uh? I run a tiny mail site and get about 1.6 new domains per hour. It is much slower than light, but still too fast for an embedded list... Any global figure, anywhere? >>> 1: Granted, the list becomes a priority list for compromise attempts, much >>> as >>> happened with ESPs several years ago, but sudden spikes in volume can be >>> treated as suspicious anyway, so the benefit in compromising a small >>> forwarder >>> is limited. >> >> Spamtraps will also work well, as usual. However, no spam indicator implies >> that the upstream ARC chain is faked. In theory, for example, ARC would >> allow >> me to switch to forward-before-filter (maybe CPU happened to cost me more >> than >> bandwidth, say.) In that case, you would tend to classify me as a spammer >> and >> possibly suspect that my keys were compromised. How to maintain the list >> remains unclear. > > You've lost me: > > * If you're forwarding unfiltered email to receivers who are able to make > good use of ARC information, and assuming that they still trust you, then > there is no problem here: you just have lousy filters. > * If you're forwarding to people for whom either of those things is false, > then you're shooting yourself in the foot. > > Don't be a bad neighbour: filter to the best of your ability, but don't sweat > the rest. Your neighbours are most unlikely to appreciate your dumping cost > onto them if you do otherwise. 100% agreed. The example —admittedly somewhat stretched— was meant to highlight the difficulty of substantiating statements like "I trust these guys not to lie in ARC signing/sealing". Best Ale -- ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] RUA vs RUF reports
Two comments: 1) Most of the failure reports I've seen haven't included the message body, they've only included the headers. So the exposure is limited. I assume limiting the exposure is the whole reason why the reports don't include message bodies. 2) The people receiving the failure reports aren't "total strangers." They are either (a) the same people who run the email infrastructure (if failure reports are handled internally), who are presumably authorized to look at email headers while troubleshooting issues, or (b) third-party data processors (to use the GDPR terminology), which are permitted as long as how they are using the data is disclosed to users. There /could be/ a GDPR issue if failure reports are sent to a third-party processor /and/ that isn't disclosed to the user, but it isn't /ipso facto/ a GDPR issue to use a third-party processor to manage failure reports. jik (I know more about the GDPR than I would like, and less than I should. :-/ ) On 5/30/18 10:56 AM, Richard via dmarc-discuss wrote: Date: Tuesday, May 29, 2018 19:35:27 -0400 From: John Levine via dmarc-discuss In article you write: I'm surprised to learn of the low value of failure reports. It's a lawyer thing. Failure reports send copies of your users' mail to total strangers. Maybe those strangers had something to do with that mail, maybe not. You can make various arguments about why even if the strangers didn't have anything to do with the mail they should get to see it anyway, but you know how lawyers are, always telling you to spend $1000 to defend against a $10 risk. I realize that enforcement of GDPR is still a work in progress, but: > Failure reports send copies of your users' > mail to total strangers. would seem to run directly against its intent. ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html) ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Newbie question: subdomain
On Wed, 2018-05-30 at 11:22 -0400, Jerry Warner wrote: > I do not have a SPF record for mail.server.com in addition to > server.com I thought it rolled back to server.com based on what I > read. As previously noted, nope. > What's the point in listing mail.server.com in the server.com > SPF if it's not looking there? In case mail.server.com sent email using the domain server.com in the envelope header. In that case, an SPF test would look up the record for server.com to see if mail.server.com was authorised to send emails for that domain (server.com). > So I need two SPF records, one for > server.com and one for mail.server.com Correct. You can use something like "v=spf1 +a -all" for mail.server.com >Both can use use the same > DKIM as long as they're both aliases to the same domain on the mail > server? I've looked, and I can't set up a second DKIM since > mail.server.com and server.com are the same in the mail server > program (imailserver). Correct. As long as the DKIM signing domain is the same you'll be fine. Ken. ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Newbie question: subdomain
just a guess but does mail.server.com have its own SPF record? Because, it won't inherit anything in the SPF for server.com and if it's also not DKIM signing those emails then that would cause your DMARC failure. I do not have a SPF record for mail.server.com in addition to server.com I thought it rolled back to server.com based on what I read. What's the point in listing mail.server.com in the server.com SPF if it's not looking there?So I need two SPF records, one for server.com and one for mail.server.com Both can use use the same DKIM as long as they're both aliases to the same domain on the mail server? I've looked, and I can't set up a second DKIM since mail.server.com and server.com are the same in the mail server program (imailserver). ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] RUA vs RUF reports
> Date: Tuesday, May 29, 2018 19:35:27 -0400 > From: John Levine via dmarc-discuss > > In article > > you write: >> I'm surprised to learn of the low value of failure reports. > > It's a lawyer thing. Failure reports send copies of your users' > mail to total strangers. Maybe those strangers had something to do > with that mail, maybe not. You can make various arguments about > why even if the strangers didn't have anything to do with the mail > they should get to see it anyway, but you know how lawyers are, > always telling you to spend $1000 to defend against a $10 risk. > I realize that enforcement of GDPR is still a work in progress, but: > Failure reports send copies of your users' > mail to total strangers. would seem to run directly against its intent. ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Newbie question: subdomain
Yeah, only the DMARC settings "trickle down" to a subdomain. Your SPF or DKIM authentication does not. It really sounds like you just need to add an SPF record for the subdomain. Cheers, Al Iverson On Wed, May 30, 2018 at 10:28 AM Ken O'Driscoll via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > On Wed, 2018-05-30 at 09:44 -0400, Jerry Warner via dmarc-discuss wrote: > > I'm reading over my reports and I see that I'm getting fails on valid > > emails sent from my server when the sender uses a mail.server.com > > name instead of just server.com. > Hi Jerry, > just a guess but does mail.server.com have its own SPF record? Because, it > won't inherit anything in the SPF for server.com and if it's also not DKIM > signing those emails then that would cause your DMARC failure. > Ken. > ___ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html) -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] General DMARC weakness - personal forwarding
On 30/05/18 06:09, Brandon Long via dmarc-discuss wrote: On Tue, May 29, 2018 at 8:10 AM Alessandro Vesely via dmarc-discuss mailto:dmarc-discuss@dmarc.org>> wrote: I know ARC proponents don't want author's domains to sign ARC-0, but never understood why. Anyway, ordinary forwarders will need to ARC sign forwarded messages too, which includes pretty much all mail sites. The latter is *not* a slow-moving data set. It grows steadily. No, ordinary forwarders which break DKIM need to ARC sign. If you're just an ordinary forwarder, why break DKIM? Plenty of ordinary forwarders break DKIM: * Essentially all customer-controlled Exchange servers. (Office 365 fixed this a while back for server-side rules, but this has not made its way into customer-controlled installations generally, or perhaps not even into the product.) * Plenty of ordinary forwarders add footers, strip attachments. Fortunately virus scanner spam has largely stopped. * Etc. I have previously singled out MIMEsweeper for gratuitous re-encoding of body parts and am pleased to report that my doing so led to that problem being fixed. 1 down, 999 to go... Cases like this will appear as a small fraction of the email volume of large receivers, but require a disproportionately large number of fixes. It may not be 1,000, but I'm certain that it's hundreds. - Roland ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Newbie question: subdomain
On Wed, 2018-05-30 at 09:44 -0400, Jerry Warner via dmarc-discuss wrote: > I'm reading over my reports and I see that I'm getting fails on valid > emails sent from my server when the sender uses a mail.server.com > name instead of just server.com. Hi Jerry, just a guess but does mail.server.com have its own SPF record? Because, it won't inherit anything in the SPF for server.com and if it's also not DKIM signing those emails then that would cause your DMARC failure. Ken. ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] General DMARC weakness - personal forwarding
On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote: * A single public whitelist is not necessary for ARC to work, multiple lists are certainly possible, but the mapping of well-behaved whitelist operators is: o much easier than mapping abusers, as the latter are seeking to _*evade*_ detection; o much slower moving (new small list operators appear at a rate of perhaps one per week; abusers gain control of IP addresses at a rate of many per second); and o more resilient in that possession of the abuse data by abusers doesn't provide a means to optimise abuse by focusing on IP addresses and identifiers that haven't yet been identified[1], meaning that a slow-moving list can be included in email security software, as with the current rule set for something like SpamAssassin. You seem to imply that only mailing list activity needs to deploy ARC. I hadn't meant to imply quite that, however the paragraph was already getting a little long so I did not elaborate further. The list operators would be a starting point for ARC reputation data, certainly; forwarding mail-servers more generally would then be an obvious refinement. Even the complete set of honestly operated mail-servers in the world - whether forwarding or not - is changing at a rate that is still orders of magnitude lower than the rate of change of IP addresses used for abuse, consequently collecting, distributing, and using this data would be relatively straightforward. I know ARC proponents don't want author's domains to sign ARC-0, but never understood why. Anyway, ordinary forwarders will need to ARC sign forwarded messages too, which includes pretty much all mail sites. The latter is *not* a slow-moving data set. It grows steadily. Steady growth *is* slow movement. 1: Granted, the list becomes a priority list for compromise attempts, much as happened with ESPs several years ago, but sudden spikes in volume can be treated as suspicious anyway, so the benefit in compromising a small forwarder is limited. Spamtraps will also work well, as usual. However, no spam indicator implies that the upstream ARC chain is faked. In theory, for example, ARC would allow me to switch to forward-before-filter (maybe CPU happened to cost me more than bandwidth, say.) In that case, you would tend to classify me as a spammer and possibly suspect that my keys were compromised. How to maintain the list remains unclear. You've lost me: * If you're forwarding unfiltered email to receivers who are able to make good use of ARC information, and assuming that they still trust you, then there is no problem here: you just have lousy filters. * If you're forwarding to people for whom either of those things is false, then you're shooting yourself in the foot. Don't be a bad neighbour: filter to the best of your ability, but don't sweat the rest. Your neighbours are most unlikely to appreciate your dumping cost onto them if you do otherwise. - Roland Best Ale ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
[dmarc-discuss] Newbie question: subdomain
I'm reading over my reports and I see that I'm getting fails on valid emails sent from my server when the sender uses a mail.server.com name instead of just server.com. I read that in this case the DMARC will default to the "organizational domain" which using their examples, would have resulted in server.com which SHOULD have passed, but instead is marked as failed. I fear I have missed something. In my spf1 file I have listed both mail.server.com and server.com "v=spf1 a mx a:server.com a:mail.server.com a:images.server.com a:www.cds.com a:smpt5.volusion.com ~all" What have I done wrong?In the example above Volusion hosts the website (but not the mail server) so it was included so that sales receipts could be emailed to customers. I believe I'd done that correctly but documentation for third partys isn't easy to come by and Volusion will only help if they're also acting as your DNS and mail server, which is not the case for me. ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
