[Top] [All Lists]

[ietf-dkim] Re: Collection of use cases for SSP requirements

2006-11-10 09:23:51
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.


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@,, ...


NOTE WELL: This list operates according to

<Prev in Thread] Current Thread [Next in Thread>