http://qs1969.pair.com?node_id=11122539


in reply to Re: Double Dot Stuffing
in thread Double Dot Stuffing

Interesting observation, but it appears that passing a string returns the same output as passing an array ref. Passing a string as the value of the paramater is even used in the source of the MIME::Entity module itself for its own internal methods (see, add_sig() ).

The docs actually state the value for the Data param should be,

Single-part entities only. Optional. An alternative to Path (q.v.): the actual data, either as a scalar or an array reference (whose elements are joined together to make the actual scalar).

So both are right. I'm very pleased with how MIME::Entity is encoding the message - one line that I feed it splitting into two lines when encoded is what I expect. Decoding things back works just as well. (I'm not reporting a bug in MIME::Entity.)

 
#!/usr/bin/perl 

use MIME::Entity; 

my $str = 'filler text to get the first char of line 2 to be a dot______ http://google.com'; 

MIME::Entity->build(
	Data     => $str, 
	Type     => 'text/plain',
	Encoding => 'quoted-printable',
)->bodyhandle->print; 
Prints back,
filler text to get the first char of line 2 to be a dot______ http://google.com

The broken URL isn't happening in my app, but upstream.

The problem is in the SMTP client not double-dotting a line that starts with a dot. Lines that start with a dot could happen because of my example (wrapping a URL onto multiple lines during encode). I'm asking what it is I should do (if anything) to deal with a broken SMTP client? I'm leaning on, "nothing", but is this instead a universal problem, with a known solution? Googling this problem specifically for Perl examples leads to no results, although other languages/libraries say to encode the dot. If I were to encode the dot, what's the least hackiest way to do so? I can make a one-line regex to handle this, but then I fear I'll then have two problems.

-skazat

Replies are listed 'Best First'.
Re^3: Double Dot Stuffing
by BillKSmith (Monsignor) on Oct 05, 2020 at 03:39 UTC
    It appears to me that a long line in the Entity object is just that - a long line. Only the display is word- wrapped. There is no issue with a line starting with a dot. If some 'upstream' software (or person) did the analogous word-wrap before the build, the object would indeed have two lines one of which might start with a period. In that case, your URL would contain a newline character right before the dot. If this does not describe the problem, please post code that builds two similar objects, one that is correct and one that is not.
    Bill
      No, that doesn't describe my problem, but I encourage you to revisit my initial post ;)
      -skazat
        In your original post, you describe the workarounds you have attempted. These are unlikely to succeed (for the reasons you suggest). You really must identify the source of the problem. If you control it, fix it. If not, submit a bug report to the responsible people. (You probably will need a temporary workaround. This should be possible once you understand what is going on.)

        Allow me to guess at the structure of your application. It receives email from an external source, and somehow creates the "MIME Entity" object. This object is expected to contain a valid URL (part of a valid HTML link??). Your application tries to link to that URL. Sometimes that link fails. You believe that the URL is missing the required 'dot', but have not explained how you know it. If this is true, it is reasonable to suspect a problem with "dot stuffing". Your example has nothing to do with this. It is crafted such that the 'as_string' method word wraps the line at the dot. There is only one line and it does not start with a dot.

        The first thing you must determine is whether the original error occurred in sending, receiving, or processing the mail. It may be helpful if you could read an offending mail with a commercial email client. If that reads it correctly, you would know for sure that the mail was sent correctly. If not, it is highly likely that the mail was sent incorrectly.

        In my earlier posts, I was guessing that you extract the URL from the as_string output and that fails in special cases. Sorry I cannot offer more help.

        Bill