Mailserver re-encoding of attachments valid ?
Hi All, While trying to help a customer that was having trouble receiving specific attachments through our mailserver, but which seemed to be received ok through another ISP's mailserver, I came across an interesting thing.... It turned out that the troublesome attachments were in UUENCODE format, and something about the way the customers own mailserver/client machines were set up were causing them problems... The strange thing was, that the same message sent through another well known ISP was being received, seemingly with no problems getting the attachment. A bit of investigation found that while our server was passing the UUENCODE'ed attachment through as-is, the other ISP is decoding the UUENCODE'ed attachment, and re-attaching it in the more common BASE64 Mime attachment type. Now I havn't looked through RFC's exhuastively, but I was under the impression that although mailservers are allowed to add their own Headers, etc, they must NOT alter the message body of a message. (Or at least, "Should not") Is this decoding of attachments and re-encoding/attaching them in a different format breaking the RFC's ? Just wondering... :) Regards, Simon Byrnand iGRIN Internet
I'm not sure about breaking RFC's, but it cant be good for cryptographically signed messages... Nathan Ward Simon Byrnand wrote:
Hi All,
While trying to help a customer that was having trouble receiving specific attachments through our mailserver, but which seemed to be received ok through another ISP's mailserver, I came across an interesting thing....
It turned out that the troublesome attachments were in UUENCODE format, and something about the way the customers own mailserver/client machines were set up were causing them problems...
The strange thing was, that the same message sent through another well known ISP was being received, seemingly with no problems getting the attachment.
A bit of investigation found that while our server was passing the UUENCODE'ed attachment through as-is, the other ISP is decoding the UUENCODE'ed attachment, and re-attaching it in the more common BASE64 Mime attachment type.
Now I havn't looked through RFC's exhuastively, but I was under the impression that although mailservers are allowed to add their own Headers, etc, they must NOT alter the message body of a message. (Or at least, "Should not")
Is this decoding of attachments and re-encoding/attaching them in a different format breaking the RFC's ?
Just wondering... :)
Regards, Simon Byrnand iGRIN Internet
_______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
A quick re-read of 2822 and the MIME rfcs indicates that while certain rewriting is permitted (to keep line-length below 982 for instance), what you've described is not explicitly allowed, however, neither is it forbidden. One thing though, was the ORIGINAL a MIME message? That is, did it claim to be MIME with version 1.0? uuencoding is not a valid MIME encoding, so one could argue that the mailserver was doing 'the right thing' in emitting correct MIME. BUT, I would say that it should at the very least include a Comment: header to mention what it had done. -- Michael Newbery IP Architect TelstraClear Limited
participants (3)
-
Michael Newbery -
Nathan Ward -
Simon Byrnand