Proxmox breaks DKIM signature

vuser1 · Aug 27, 2010

Proxmox is not compatible with DKIM/DomainKeys.

This is message source, as seen from gmail "Sent mail":

Code:

MIME-Version: 1.0
Received: by 10.220.78.157 with HTTP; Thu, 26 Aug 2010 21:33:17 -0700 (PDT)
Date: Fri, 27 Aug 2010 12:33:17 +0800
Delivered-To: disabled01@gmail.com
Message-ID: <AANLkTi=gRYToyfyj7AC5UhmBhPArr7dus+hJ-Xah_+Ym@mail.gmail.com>
Subject: Hello
From: disabled01 <disabled01@gmail.com>
To: disabled@test123.ru
Content-Type: multipart/alternative; boundary=90e6ba4fc6ea25d329048ec69d99

--90e6ba4fc6ea25d329048ec69d99
Content-Type: text/plain; charset=ISO-8859-1

HELLO

--90e6ba4fc6ea25d329048ec69d99
Content-Type: text/html; charset=ISO-8859-1

HELLO<br>

--90e6ba4fc6ea25d329048ec69d99--

This is what my internal postfix server (it has postfix-dkim-filter installed) gets from proxmox frontend:

Code:

Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.212.45 is authorized to use 'disabled@gmail.com' in 'mfrom' identity (mechanism 'ip4:209.85.128.0/17' matched)) receiver=proxmox.test123.ru; identity=mfrom; envelope-from="disabled@gmail.com"; helo=mail-vw0-f45.google.com; client-ip=209.85.212.45
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=dk4ZvRJYySWcUzJ+Lfz5a53IiT4Sv8cxpPbXVWCtq5B0wFayZj/uNI1kQ4RAyiiyN+
         +QrAB613+kTgT97k6gZT1UCGuNwT2sje7o1Cgzg+UlrSFeJvkmT2EKdVo37OgZJT4jCk
         6HGDTIH9W3OCJ/6qpiY/U8Z5GOzSR5jbFuPfM=
MIME-Version: 1.0
Date: Fri, 27 Aug 2010 12:33:17 +0800
Message-ID: <AANLkTi=gRYToyfyj7AC5UhmBhPArr7dus+hJ-Xah_+Ym@mail.gmail.com>
Subject: Hello
From: disabled <disabled@gmail.com>
To: disabled@test123.ru
Content-Type: multipart/alternative; boundary=001636ed782a26507e048ec69d6d


--001636ed782a26507e048ec69d6d
Content-Type: text/plain; charset=ISO-8859-1

HELLO

--001636ed782a26507e048ec69d6d
Content-Type: text/html; charset=ISO-8859-1

HELLO<br>

--001636ed782a26507e048ec69d6d--

As you see, DKIM signature is invalid. Problems
1) Boundary changed
2) Extra CRLF between header block and message body

Same problem appears when my internal postfix sends mail through proxmox. It inserts extra CRLF between headers and body. It breaks the signature made by internal server. When UA composes a message as <HEADER><CRLF><CRLF><BODY>, everything is OK. But for the message <HEADER><CRLF><BODY>, proxmox inserts extra CRLF. It does not change boundary for outgoing messages.

Any solution? Did I something wrong?

dietmar · Aug 30, 2010

vuser1 said:
1) Boundary changed

So who/what changes the boundary?

vuser1 · Aug 31, 2010

Good question. I did more experiments. Gmail shows different boundary in "view source" of "Sent mail" folder. When it sends the message, it uses another boundary.

Boundary is OK.
The only problem is extra CRLF.

dietmar · Aug 31, 2010

vuser1 said:
The only problem is extra CRLF.

OK, I was able to reproduce that behavior. Our MIME Framework expects a text area before the first mime boundary. Usually something like: "This is a message with multiple parts in MIME format."

see http://en.wikipedia.org/wiki/MIME]

Before the first boundary is an area that is ignored by MIME-compliant clients. This area is generally used to put a message to users of old non-MIME clients.

Our framework insert an empty line if that area does not exist.

I suggest that you simply insert such text, as I consider that 'good' practice anyways.

- Dietmar

dietmar · Aug 31, 2010

BTW, what software creates that multipart message?

dietmar · Aug 31, 2010

I just reread RFC 1341 (MIME)

see http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain). NOTE: The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, should have two CRLFs preceding the encapsulation line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.

In fact, the leading CRLF is required by the RFC - so your MIME message is invalid, and the mail gateway corrects that. So the solution for you is to generate valid MIME messages.

vuser1 · Aug 31, 2010

dietmar said:
I just reread RFC 1341 (MIME)
In fact, the leading CRLF is required by the RFC - so your MIME message is invalid, and the mail gateway corrects that. So the solution for you is to generate valid MIME messages.

Ha-ha, please tell this to gmail developers. And to roundcube as well. And - unbelievable - yahoo! That is the software you were asking about. Tell them that theirs online message composers are invalid. Force them to fix that.

Now seriously. Electro-mail is angry beast. There are tons of clients, they break *everything* - starting from POP3 protocol, ending by putting two Sender headers. That's why we have options like _imap_client_workarounds_ in software like postfix or dovecot. That's why I use proxmox - I simply have no time and knowledge to build good filtering gateway.

Please, notice - roundcube+postfix+dkim-filter standing behind proxmox always produce broken signature. The workaround is not to use proxmox for sending. Looks like for receiving messages there is no workaround yet.

dietmar · Sep 1, 2010

vuser1 said:
Ha-ha, please tell this to gmail developers. And to roundcube as well. And - unbelievable - yahoo! That is the software you were asking about. Tell them that theirs online message composers are invalid. Force them to fix that.

Well, I don't see what so funny here. Anyway, the spec is unclear, and I guess it can be interpreted both ways.

I assembled a fix for that - please can you test?

# wget ftp://download.proxmox.com/tmp/libmime-perl_5.420-2_all.deb
# dpkg -i libmime-perl_5.420-2_all.deb

and restart the filter daemon

# /etc/init.d/proxprox restart

vuser1 · Sep 2, 2010

It does not install on v2.6

Code:

mail:~# dpkg -i libmime-perl_5.420-2_all.deb
dpkg - warning: downgrading libmime-perl from 5.427-1 to 5.420-2.
dpkg: regarding libmime-perl_5.420-2_all.deb containing libmime-perl:
 libmime-tools-perl conflicts with libmime-perl (<< 5.425-2)
  libmime-perl (version 5.420-2) is to be installed.
dpkg: error processing libmime-perl_5.420-2_all.deb (--install):
 conflicting packages - not installing libmime-perl
Errors were encountered while processing:
 libmime-perl_5.420-2_all.deb

tom · Sep 2, 2010

we do not use 5.427-1, so its clear that you do not use a standard Proxmox Mail Gateway!?

vuser1 · Sep 3, 2010

My fault. This was my internal mailserver. I completely forgot that proxmox is another machine

The patch works! Thank you very much!

Search

Search

Proxmox breaks DKIM signature

vuser1

New Member

dietmar

Proxmox Staff Member

vuser1

New Member

dietmar

Proxmox Staff Member

dietmar

Proxmox Staff Member

dietmar

Proxmox Staff Member

vuser1

New Member

dietmar

Proxmox Staff Member

vuser1

New Member

tom

Proxmox Staff Member

vuser1

New Member