[dmarc-ietf] Re: I-D Action: draft-ietf-dmarc-arc-to-historic-00.txt

[Tero Kivinen <[e-mail]>]

Douglas Foster writes:
> Tero, you illuminate an important issue, but you confuse the
> boundary between the filtering system admin and the individual user.

Nope. System should not filter emails on this level, filtering should
happen on the request of the individual user. In some contries laws
actully forbid operators to filter emails unless they cause technical
harm (i.e., huge volumes, actual hacking attemps etc). 

> To effectively filter forwarded mail, the filtering system needs to
> know whether the forwarding path has been requested or not.   This
> applies whether the forwarder is a mailing list or a redirected user
> account.    

Why should the system need to know that? I have multiple friends who
actually want to receive every single spam email, phishing attacks etc
as they want to store them for statistical analysis.

Then there are lots of people who consider every single spam email in
their mailbox as attacks against them and do not want to get any of
them.

System level filterin can never satisfy both of them. To satisfy them
the system needs to do user level filtering where users preferences
are taken into account.

This also includes the list of trusted forwaders which are used when
doing spam etc filtering on the emails.

I usually whiteliste all mailinglist I am subscribed to because there
are way too much discussion there which could be caught by spam
filters if I would actually run them through it.

> GoogleGroups and Outlook groups are routinely used to create mailing
> lists to which no one has ever subscribed.   That allows the
> attacker to use these services as if they were open relays. 

That is why the having ARC header that says that mail came through
those systems is just one rule used for the spam filtering. Having
mailinglist names which you are not part of is one of the other rules
which should increase the likelihood that email is marked as spam.

Also if each of the mailing lists used different signer, i.e., would
appear as separate forwarding systems this would solve that problem
(i.e., set s=<mailinglistname> and generate separate keys for each
list/group).

> DKIM reply is only possible because filtering systems do not know
> whether a forward is subscribed, and therefore legitimate, or not. 
>  Therefore, any filtering system that accepts forwards SHOULD have
> administrative controls in place to determine if a forwarding path
> is acceptable.   For redirected user accounts, the forwarding system
> admin should also be involved to review whether the forward is
> compliant with local policy and correctly configured to an account
> that actually wants the mail stream.   Strangely, the environments
> that receive the most forwarded traffic seem to have the least
> interest toward establishing those controls.  ARC cannot fix
> ignorance or user preferences.

Each forwarding system should verify that when the forwarding is
requested the requester must be able to receive emails in the address
where the mail is forwarded to. I.e., send email verification to the
given address and ask user to verify recipient of it (clicking link,
typing code in it etc). This verification email should have same ARC
headers as forwarded emails are going to have, so that user can at the
same time configure their system to recognize them.

> Sometimes, forwarded traffic is hard to detect.  If ARC is present,
> it should help to distinguish between traffic handled by a forwarder
> and traffic handled by an outbound gateway service.
> 
> As long as the filtering system is ignorant of user preferences, it
> does not matter that the user knows which forwarded mail streams are
> legitimate.

Thats why filterin system needs to know user preferences.
-- 
[e-mail]