SOLVED: Emails coming thru blank....

[bluemike]

There is nothing in the fatal logs that applies.

I will stay on it, and update this posting with any new information.

Right now, I am caught in the 'problem is x' loop. Scalix is telling me it's Squirrelcart problem, and Squirrelcart is telling me it's a Scalix problem. It's a regular love triangle ;-)

[ScalixSupport]

Please can you ask Squirrelcart why they are sending a blank attachment at the end of the message.

Cheers

Dave

[bluemike]

That's kind of the trick. They have sent me the source code that generates the emails notifications, and it's not there. :(

[ScalixSupport]

It depends what you're looking for. The text/plain - US-ASCII details are something that was add because of the presence of an attachment with zero MIME information but, as you showed us in the smtpd trace, the boundary/end-boundary combination is most definitely being sent from Sqirrelcart.

Cheers

Dave

[bluemike]

But since these emails look fine in every other concievable email retreival method, wouldn't that tend to make this a Scalix issue rather than a Squirrelcart issue?

As far as why that boundry thing is there, SC is saying this:

The email content you sent is being altered by something other than Squirrelcart. Squirrelcart does not add this to any emails:

--==Squirrelcart-Mail-Boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I did a full text search for every file in version 2.1.4, and cannot locate the text "US-ASCII". An extra boundary is being added as well, so something is reading the email, locating the boundary from the headers, and then adding that text/plain section.

I'm sorry I can't be more self-sufficient on this. I am a bit out of my element here.

[ScalixSupport]

Let's say for the moment that reading a blank body part in a non-MIME aware client is a Scalix issue, it doesn't explain the blank body part in the first place.

As I said, looking for US-ASCII through the Squirrelcart source code isn't going to help as it's something that we add to a default attachment with zero MIME information.

Take a look at the smtpd.log you sent us, at the very end of the message, just before the QUIT command, you can see the boundary marker immediately followed by the end-boundary marker. This is what the sending client gives to Scalix, it's not anything that Scalix will have added to the end of the message. A combination of those two markers is a default blank body part, there does not have to be any MIME information to make it a body part.

Cheers

Dave

[bluemike]

Well, this is no longer a problem. As it turned out the ecom software was missing just a single dash in one tiny little spot. That buggered up the whole works.

They have fixed it now, and all is well.

I want to thank everyone, particularly Dave and Florian, for their patience and help. I know that, were the situations reversed, I probably would have written me off long ago.

Anyhoo, thanks again!