Thanks for the quick response Hector,
On Tuesday 29 September 2009 17:36:57 Hector Santos wrote:
Why not just make it simple with across the board DKIM/ADSP protocol
consistency?
Because I can't deploy DKIM validation on a 3000 user gateway an deal with all
the failures because there are (or will be) DKIM=DISCARD|ALL domains out there
who post to email lists that the user base legitimately subscribes too.
All DKIM/ADSP compliant receivers (including hops, routers, list
servers) who see a failed ADSP condition honor the author
domain wishes and reject/discard/etc (not deliver) it.
To begin adding subjective non-standard ideas,
the DKIM/ADSP RFC leaves assessment of the filtering out of scope AFAIK.
software change requirements just complicates it and reduces the confidences
level for false/true positives.
the confidence level is low now as false negatives occur and all I've got to
deal with them is an on-ADSP-fail=discard/accept switch. I'd like something a
little more flexible hence I put my desired whitelists out as an idea even if
it means taking some little risk.
In addition, the list server should help the process by adding to
their respective subscription procedure a ADSP check for restrictive
policies (DKIM=DISCARD|ALL).
so list operators should discard DKIM=DISCARD|ALL subscribers if they mangle
email on the way though? Possible with a simple header regex I suppose. Are
you really serving the interests of the domain owner though?
Do you have any comment with the other post about fixing mail lists by changing
the From address?
Is some temporary whitelist logic until MLS become DKIM=DISCARD|ALL friendly
an unreasonable request?
Why bother allowing these restrictive
ADSP domains to subscribe when the DKIM/ADSP compliant down links
(MDAs) are going to reject/discard (or SHOULD) any failure from the
mailing list?
Probably the complacent approach that if there's not an option to do this an
operator won't bother. Also the initial rejects could be so low its not worth
worrying about. Another opinion is they would rather there were more
subscribers to there cause even if there are occasional technical difficulties.
I don't think operators would feel comfortable removing DKIM=DISCARD|ALL
subscribers at the point where rejection messages increase. I hope this
motivates them to removal message alteration settings before this occurs. In
the mean time their 'unreliable' service may have caused community damage.
- The MLS blindly allows a ADSP domain to subscribe,
- The MLS gets a DKIM signed messages from the domain,
- The MLS strips/destroys and resigns as a 3rd party.
- The MLS distributes (lets assume 1000 endpoints)
You have two types of receivers:
A) SMTP level filtering at the DATA level
B) POST SMTP filtering (the one ADSP was designed for)
Though you could do this post smtp how many implementations do? A DNS query
after a From header can easily be processes before end of DATA. Not
particularly relevant to discussion though.
For A, the DATA is received allowing for RFC5322 header analysis,
specifically a ADSP domain check.
Test #1 DKIM=DISCARD|ALL, NO SIGNATURE
--> REJECT, REPLY CODE 550
Test #2 DKIM=DISCARD|ALL, INVALID SIGNATURE
--> REJECT, REPLY CODE 550
Test #3 DKIM=UNKNOWN, NO SIGNATURE
--> DATA ACCEPT, REPLY CODE 250
Test #4 DKIM=UNKNOWN, INVALID SIGNATURE
--> Add Authentication-Results header header
--> DATA ACCEPT, REJECT, REPLY CODE 250
This is a RFC 2821 compliant,
ok
socially acceptable,
to the domain owner who put in a dkim=discard record sure. In theory they have
read and understood rfc5617 4.2.1:
"the domain encourages the recipient(s) to discard it"
to the sender from that domain where one recipient does receive it - probably
not that concerned. though on small lists it could be.
to the local staff I support its not socially acceptable for email list
delivery to work one day and not the next.
its not socially acceptable when my only manageable option is to turn ADSP
verification on or off.
included US EPCA..., RFC 5381 "cracked open" the door to allow for
POST SMTP reception to silently "discard" mail deemed suspicious.
Hence why ADSP has DKIM=DISCARD (not REJECT) although at the SMTP
level DKIM=DISCARD will be interpreted at a REJECT.
ah - interesting - hadn't looked at this before.
The difference is the lost of notification - conflictive with US EPCA "User
Expectations" provisions.
I'm not in the US so I don't care that much about this.
All would of been resolved if the LIST SERVER preempted the situation
by honoring ADSP and not accepting ADSP domain members.
I hadn't thought of that solution before. I was too much thinking along the
lines of:
1. LIST SERVER's should replace the From address to their own domain
2. LIST SERVER's should disable content manipulation (and have a global
dkimfriendly=true option)
3. provide a verification work around until 1 or 2 is done.
In order to create an inclusive environment for everyone I don't think
"participate in email lists or set dkim=unknown" is a really good message.
I'd like to deploy DKIM=ALL|DISCARDABLE on some domains and feel confident that
verifying software can handle it.
I would of thought the DKIM=ALL is just a final step after an organisations
signs all their email without having to consider the MLS breaks.
How is DKIM going to take off?
Signing is easy. Verification rules are easy. But how do I do filtering in a
way
that doesn't leave me in one of the following battles:
1. with email list operators who don't want to change settings
2. with email list operators who do want to help but can't find all the 'dkim-
friendly' settings on the software
3. with sender who have DKIM=ALL|DISCARDABLE, as you suggested, who's users
aren't using the domain in that way
4. and with my users who are not getting some email while the above
correspondence is taking place
I'm still searching for answers on how to deploy DKIM verification on large
domains and do filtering on it with the impending ADSP adoption.
--
Daniel Black
Infrastructure Administrator
CAcert
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev