[EAI] Re: SPF and DKIM
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EAI] Re: SPF and DKIM



"abel" <abelyang at twnic.net.tw> writes in gmane.ietf.ima:

> Do we discuss those more ?

I think that we should.

> 1. As I know in SPF
>     SPF TXT record listed where  my email come from list in this domain ,
> 
>     A example in downgrading :
> >>ehlo twnic.net.tw
> >>mail from: <UTF8 at twnic.net.tw>  ALT-ADDRESS=ASCII at gmail.com  # EAI-aware
> >>rcpt to:<UTF8 at other.domain>     # non-EAI-aware
> 
> when the downgraded mail transmits , if other.domain run SPF check, we can
> pass in SPF helo check ,but fail in SPF  sender check (ascii at gmail.com) if
> gmail.com SPF records with -all unless gmail.com adds SPF for us,
> but it seems impossilbe to do that.

Yes, but that do not much differ from  
     ehlo twnic.net.tw
     mail from:<ASCII at gmail.com>

I think that there is no new restrictions.

On general if you have
     ehlo twnic.net.tw
     mail from: <UTF8 at twnic.net.tw>  ALT-ADDRESS=forwarder at gateway.example


if gateway.example ia providing forwarding service, it practically 
can not provide SPF records --  not providing SPF records is part
of service. 


> Fujiwara's downgrade-03 draft said 'more detailed consideration is required'
> in Section 5, But I think that SPF sender check will break ALT-ADDRESS
> without
> restriction.





> 
> 2. DKIM
>     Header change (downgraded / drop ) maybe break the signatures,

Also header change ( conversion to UTF-8 by IMAP/POP server) may 
break signatures. This also need to be discussed.

 
> a downgraded mail keeps the original header can follow DKIM, but DKIM
> should know how to verify and reduction.
> 
> 2.1 Downgrading after DKIM, some header value has changed by downgrading
>    procedue when transmits, DKIM verifier should restores 'Downgraded:'
>    header to verify, and all 'Downgraded:' headers are above
> 'DomainKey-Signature'
>    header.

A)

That requires that Donwgrading -undo algorithm ('upgrade')
in draft-ietf-eai-downgrade really returns original header fields.
Currently there is:

     *  If each mail header has [RFC2047] encoded part and which
         encoding is "UTF-8", it is a downgraded header, so decode it.

This does NOT fill these requirements.  

Currently 'downgrade' part of algorihm even do not preserve
original header fields (except address header fields) to
'Downgraded:' -header fields.


If algorithm is modified and original header fields are preserved
on Downgraded: -header field, on Donwgrading -undo algorithm there
is little problem -- it needs to know which one header fields must
discard -- it must discard correspond downgraded header field, 
when restoring data from Downgraded: -header field -- otherwise
more header fields with same name is generated than on original message.

B)

DKIM signature verify may accur on agent which do not know about
UTF8SMTP protocol -- therefore it will not know how to upgrade header fields.

That also causes that DKIM signature verify fails.

To prevent that downgrading need to move DomainKey- -header fields
to Downgraded: -header fields and destroy original header fields.

... problem there is that downgrade procedure needs know every signing
    protocol ...


( You may want compare how I proecess exatcly this same promlem
  on my draft-hurtta-eai-encapsulation-00.txt  draft. )


> 2.2 Downgrading before DKIM, DKIM signs the downgraded headers, it's
> possible
>    to include 'h=Downgraded:' in 'DomainKey-Signature', all 'Downgraded:'
>    headers are under DomainKey-Signature header, DKIM verifier should verify
>    all 'Downgraded:' headers if there are 'Downgraded' in tags 'h='
> 
>    And we still need to more consideration about the downgrading impact  in
>    DomainKey-Signature  tags 'd=' (domain) 'i=' (sender) 'z=' (header name
>    and header values in quoted-printable) or more.
> 
> 
> 
> If we drops header values (such as uFor or others ) and the headers are
> signed in
> 'DomainKey-Signature' will cause Domain Key verifier  treats as a bad
> signature
> if they do not appear ,especially in trace field, that's fine in trace filed
> rule
> and DKIM siner/verifier issue.

/ Kari Hurtta


_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.