RE: octet-stream attachment

If you can look at the message in Outlook, can't you just forward it to an account on a Unix box so that we can see the mime headers properly?

> The latter two say the attachments had names ending in .jpg and .pdf (the
> two aberrant examples I've seen). The first says they were ".jpg_" and
> ".pdf_".

> Daniel says:
> > Hypermail saves the file with the name it got supplied. If
> > the file name had a ".jpg_" extension it will be used.
>
> V2a23 is most certainly prepending "att-" to the attachment name. And
> parse.c defines "REPLACEMENT_CHAR" as '_', "to replace invalid characters
> in supplied attachment filenames." Seems like an EOL mishandling, as Paul
> Haldane suggested earlier.
>
> But his proposed fix:
> RCS file: /cvs/hypermail/hypermail/src/parse.c,v
> retrieving revision 1.20
> diff -r1.20 parse.c
> 1222c1222
> < sscanf(fname, "%128[^\"]", attachname);
> ---
> > sscanf(fname, "%128[^\"\n]", attachname);
>
> did not do the trick.

Worked for me - but I was guessing at the format of the name= line.

> I looked at the "safe_filename" function in that
> file, and the other sscanf statements... I notice one suggestive comment,
>
> /* we could've done this with a %n in the sscanf, but we know all
> sscanfs don't grok that */

Nope - %n means return a count of characters read so far (at least on my system) - no relevant.

> Someone more conversant with parse.c and the parsemail() function where the
> above sscanf is can probably track this down from these clues.

Until we see the mime headers of one of the messages, we're just guessing. We can be sure that the last character is outside the set a-zA-Z0-9:_.- (since that's what safe_filename uses as a set of 'safe' characters) but can't really tell any more that that.

A test message from Notes with an attachment is what we need.

Paul Received on Fri 30 Jul 1999 10:57:02 AM GMT