Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
unfolding header lines in TIdAttachment[File]
#1
First of all, thanks to you guys for having this forum running!
I did try to post on embarcodero but it seems to be cold dead.
My problem is in sending an attachment with TIdSMTP v.10:

Code:
TIdMsg *IdMsg;
//...
TIdAttachmentFile *attchmnt=new TIdAttachment(IdMsg->MessageParts, "filename.txt");
attchmnt->FoldLines=false; - ?
attchmnt->UnfoldLines=true; - ?
IdMsg->Send();

this message does arrive to its intended destination with proper attachment, but the receiving server wants
the attachment header lines to be unfolded and header fields to be  separated by "; " (semicolon followed
by a space). So, where do I go to satisfy this server? Thanks in advance. Boba TC.
Reply
#2
(06-08-2018, 01:42 AM)Boba TC Wrote: First of all, thanks to you guys for having this forum running!
I did try to post on embarcodero but it seems to be cold dead.

Yes, sadly the Forums at forums.embarcadero.com are dead, and the Forums at community.embarcadero.com really suck.

(06-08-2018, 01:42 AM)Boba TC Wrote:
Code:
attchmnt->FoldLines=false; - ?
attchmnt->UnfoldLines=true; - ?

Those are properties of TIdHeaderList, and TIdAttachmentFile (more generally, TIdMessagePart) has a public Headers property that is a TIdHeaderList:

Code:
attchmnt->Headers->FoldLines = false;
attchmnt->Headers->UnfoldLines = true;

Both FoldLines and UnfoldLines are True by default.  UnfoldLines is used when receiving.  FoldLines is used when sending.

(06-08-2018, 01:42 AM)Boba TC Wrote: the receiving server wants the attachment header lines to be unfolded

Why?  That is not standard practice for SMTP.

(06-08-2018, 01:42 AM)Boba TC Wrote: and header fields to be separated by "; " (semicolon followed by a space).

It is not possible to have multiple *headers* in a single line, that is not even legal to do, per RFCs.  By *fields*, are you thinking of *per-header attributes*, and not multiple *headers*?  Individual *attributes* can be on a single line, separated by "; ".  Indy already handles exactly that, if you use the TIdHeaderList.Params[] property to assign the attribute values.

Reply
#3
Thanks for you prompt reply, Remy.

(06-08-2018, 02:13 AM)rlebeau Wrote: ... FoldLines is used when sending.

then it just does not do what it should.

(06-08-2018, 02:13 AM)rlebeau Wrote:
(06-08-2018, 01:42 AM)Boba TC Wrote: the receiving server wants the attachment header lines to be unfolded

Why?  That is not standard practice for SMTP.

I am not sure about "standard practice for SMTP"; the RFC does allow it.

(06-08-2018, 02:13 AM)rlebeau Wrote:
(06-08-2018, 01:42 AM)Boba TC Wrote: and header fields to be separated by "; " (semicolon followed by a space).

It is not possible to have multiple *headers* in a single line, that is not even legal to do, per RFCs.  By *fields*, are you thinking of *per-header attributes*, and not multiple *headers*?  Individual *attributes* can be on a single line, separated by "; ".  Indy already handles exactly that, if you use the TIdHeaderList.Params[] property to assign the attribute values.

I mean each header (single parameter) on a single line, like:

Code:
Content-Type: text/plain; charset="US-ASCII"; name="filename.txt"

instead of

Code:
Content-Type: text/plain;
       charset="US-ASCII";
       name="filename.txt"

I think they are called Values; so how do I ask Indy to put all values of every Name on a single line?
Also, compiler complains: " E3216 'Params' is not a member of TIdHeaderList"; do I need to update the Indy package? header files say "rev. 20.00" - 10 years old; is it too old?

One more thing... Will I be able to build the latest version of Indy Sockets/Protocols with BDS 12.0?
Reply
#4
(06-08-2018, 12:21 PM)Boba TC Wrote:
(06-08-2018, 02:13 AM)rlebeau Wrote: ... FoldLines is used when sending.

then it just does not do what it should.

Yes, it does.  If you set FoldLines=False, then headers are not folded, each header takes up only 1 line.  If you have an example that is not working, please show it.

(06-08-2018, 12:21 PM)Boba TC Wrote: I am not sure about "standard practice for SMTP"; the RFC does allow it.

The general email RFCs, yes.  But SMTP imposes limitations on line lengths, so long headers should be folded.

(06-08-2018, 12:21 PM)Boba TC Wrote: I mean each header (single parameter) on a single line, like:

Code:
Content-Type: text/plain; charset="US-ASCII"; name="filename.txt"

instead of

Code:
Content-Type: text/plain;
       charset="US-ASCII";
       name="filename.txt"

That is exactly what FoldLines controls.

(06-08-2018, 12:21 PM)Boba TC Wrote: I think they are called Values; so how do I ask Indy to put all values of every Name on a single line?

I already showed you how.

Also, TIdHeaderList has a FoldLength property, which you can set to MaxInt, for instance.

(06-08-2018, 12:21 PM)Boba TC Wrote: Also, compiler complains: " E3216 'Params' is not a member of TIdHeaderList"; do I need to update the Indy package?

Yes.  The Params property (amongst others) was added to TIdHeaderList way back in 2010.

(06-08-2018, 12:21 PM)Boba TC Wrote: header files say "rev. 20.00" - 10 years old; is it too old?

Very old.

(06-08-2018, 12:21 PM)Boba TC Wrote: One more thing... Will I be able to build the latest version of Indy Sockets/Protocols with BDS 12.0?

Yes (is that XE5?).  Indy still supports all the way back to Delphi 5 (though it requires some codegen patches for D5, but not D6+).

Reply
#5
Thank you, Remy, for the info. I will post back with my findings.
Reply
#6
Using Indy10, I am trying to create an eMial message with attachment.
This is what I would like to see in attachment header on the receiving server side:

Code:
Content-Type: text/plain; charset="US-ASCII"; name="testfilename.txt"
Content-Disposition: attachment; filename="testfilename.txt"
Content-Transfer-Encoding: base64
but this is what I get:
Code:
Content-Type: text/plain; charset="US-ASCII"
        name="testfilename.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment
        filename="testfilename.txt"
please note that values in both 'Content-Type' and 'Content-Disposition' are folded.
And this is the code fragment I use:
Code:
TIdMsg *IdMsg;
TIdSMTP *IdSMTP;
//...
TIdAttachmentFile *attchmnt = new TIdAttachmentFile( IdMsg->MessageParts, "testfilename.txt" );
//attchmnt->Headers->FoldLength = 128;
attchmnt->Headers->FoldLines = false;
attchmnt->ContentType = "text/plain; charset=\"US-ASCII\"";
//attchmnt->ContentType = "text/plain; charset=\"US-ASCII\"; name=\"testfilename.txt\"";
IdSMTP->Connect();
IdSMTP->Send(IdMsg);
If I uncomment the line where attchmnt->ContentType is set, my message arrives with
Code:
Content-Type: text/plain; charset="US-ASCII"; name="testfilename.txt"
        name="testfilename.txt"
and the GUI is almost happy: it shows the attachment properly but when users try to save it to file, 
the file name shows as "testfilename.txt        _testfilename.txt_" with 8 spaces in the middle
and 2 underscores which scares the **** out of'em  Big Grin. I am sure there is a fix. TIA.
Reply
#7
(06-10-2018, 01:53 AM)Boba TC Wrote: This is what I would like to see in attachment header on the receiving server side:

Code:
Content-Type: text/plain; charset="US-ASCII"; name="testfilename.txt"
Content-Disposition: attachment; filename="testfilename.txt"
Content-Transfer-Encoding: base64

After reviewing Indy's code, I'm sorry to say that you will not be able to achieve that format without altering and recompiling Indy's code.  The folding is hard-coded in TIdMessageClient.SendBody(), it is not even being handled by TIdHeaderList at all.  So setting the folding setting of TIdAttachmentFile->Headers has no effect, like I thought it would.  I have created a ticket for this issue:

#215: TIdMessageClient.SendBody() should respect header folding settings for message parts.

But, you should also complain to the author of the GUI that it requires unfolded formatting to begin with, that it is not processing folded headers correctly.  All of the major email senders fold headers to some degree, the GUI needs to be able to handle that.

(06-10-2018, 01:53 AM)Boba TC Wrote: If I uncomment the line where attchmnt->ContentType is set, my message arrives with
Code:
Content-Type: text/plain; charset="US-ASCII"; name="testfilename.txt"
        name="testfilename.txt"

I am not able to reproduce that.  Using the latest SVN revision, I get only 1 "name" attribute no matter how I assign the attachment's ContentType and FileName properties.

(06-10-2018, 01:53 AM)Boba TC Wrote: the GUI is almost happy: it shows the attachment properly but when users try to save it to file, 
the file name shows as "testfilename.txt        _testfilename.txt_" with 8 spaces in the middle
and 2 underscores

Then the GUI is faulty and needs to be fixed.

Reply
#8
Remy;
Many thanks for your time and attention to the issue. I am working on it as well.
> you should also complain to the author of the GUI... Then the GUI is faulty and needs to be fixed.
unfortunately, the 'unhappy' SMTP server and the GUI belong to the Google Inc.  Sad
Reply
#9
(06-12-2018, 12:40 AM)Boba TC Wrote: unfortunately, the 'unhappy' SMTP server and the GUI belong to the Google Inc.  Sad

I seriously doubt that Google would create something that is not RFC compliant, let alone *require* unfolded headers. I've used Indy to sent plenty of emails via SMTP to GMail and it has always worked fine, folded headers and all. Something else is likely going on.

Reply
#10
well, believe it or not, but the server is SMTP.GMAIL.COM and the GUI is 'Google Chrome'.
//where do I mark this thread as 'answered'?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)