Jim Fenton wrote:
> we got input from several people that laws in the EU
prohibit an email
> service provider from honoring instructions from a
purported sender to
> drop messages from others.
IANAL etc., but please note "drop" here...
> this could probably be resolved by having those subject
to these
> regulations just not implement message rejection
...and "rejection" there. Potentially DROP can
violate laws or RFC 2821.
OTOH "reject" can't be illegal anywhere, nobody's
forced to accept spam,
and if it's a false positive the sender gets a non-delivery
notification.
Of course receivers should check that a "purported
sender" really is the
originator before accepting "suspicious" mails,
but that's another issue.
> In any case, the notion of "Suspicious" was
chosen to not be too
> specific, but cover the case where the verifier (for
example) rejects
> messages which are suspicious.
My POV is exactly the opposite of your concept, "of
course" (?) "reject
is okay", and receivers could get a similar effect with
"drop", but they
better discuss this with their legal department. While
they're at it
they should also discuss any legal issues of sending bounces
to innocent
bystanders, especially complete malware - only relevant for
receivers
implementing a "reject" after their "you
lose" point (= their border MX).
> Having the information in more than one place means you
need to define
> what happens in the event of conflict.
Receivers pick what they like better, if in doubt
"reject" is always the
best action at their border, after that it turns into
"better deliver or
be damned". It's not the problem of the receiver if a
sender screws up.
And some receivers supporting DKIM won't bother to check SSP
or SPF or
what else, like some receivers supporting SPF won't bother
to look into
SSP, unless they also do DKIM. Receivers are free to do
whatever they
like - as long as they're extremely careful with DROP and
BOUNCE... 
> "I send no email" is not really a DKIM
policy, it's a mail policy.
> I'm concerned about there being a slippery slope of
policies if we
> venture outside DKIM. But we can probably manage that,
so this is
> more of a principle than something that doesn't work.
+1
> I'm not crazy about tying this to SPF records. I
expect that some of
> the problems that are reported via this mechanism will
have to do with
> unexpected forwarding through agents that modify the
message in some
> way, and in those cases SPF is also likely to fail.
Reporting 551-errors (incl. its SPF-emulation after
forwarding) works
as designed in RFC 821. It doesn't work this way for random
reports
and auto-replies (SenderID, DKIM, C/R, etc.), unless it's
based on a
PASS or minimally on some kind of "not-FAIL". If
the Return-Path is
out the next stops are postmaster , abuse,
rfc-ignorant.org, ...
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://
mipassoc.org/dkim/ietf-list-rules.html
|