mail FROM spamcop process not MIME compliant

[JFX]

Hello,

A user indicated she was no longer getting email from spamcop following submission of spam as email attachments.

It'd been a while since I had used that route instead of the web interface so I tried one. Nothing arrived so I went to my bookmarked SC page which indicated an error had occured due to our system bouncing / rejecting the reply from SC. The page offered a button to press when the problem was resolved.

We use (the fabulous) Mercury32 (www.pmail.com) and MIME compliance had recently been enabled on the SMTP server. The reply mail from SC was rejected because Mercury said it was not MIME compliant.

Is this going to change? My preference is to keep this check enabled.

Mercury's helpfile describes the compliance check as follows:

Refuse non-MIME messages

MIME has been the dominant Internet standard for formatting electronic mail since 1992, and there is no longer any justification for mail systems not to use it. Turning this flag on tells Mercury that only mail with valid MIME signatures should be accepted; it is especially useful when combined with pure HTML refusal (see above).

[jseymour]

Is this going to change? My preference is to keep this check enabled.

Mercury's helpfile describes the compliance check as follows:

Refuse non-MIME messages

MIME has been the dominant Internet standard for formatting electronic mail since 1992, and there is no longer any justification for mail systems not to use it. Turning this flag on tells Mercury that only mail with valid MIME signatures should be accepted; it is especially useful when combined with pure HTML refusal (see above).

I interpret this to mean that messages with NO MIME headers will be rejected - not just messages with BAD MIME headers.

This is, in my opinion, loony.

[jcrm]

I quite agree -- rejecting text only messages seems pretty daft, but this appears to be software for MSWindows

[JFX]

From further reading I've done, it would appear that most automatic mailers are not MIME compliant at this point in time.

"software for windows" has got nothing to do with it...

Mercury is a free, standards-based mail server solution, providing comprehensive, fast server support for all major Internet e-mail protocols. It is supplied in two versions, one hosted on Windows systems, the other running as a set of NLMs on Novell NetWare file servers.

... but standards do.

http://www.ietf.org/rfc/rfc2045.txt

[WB8TYW]

I do not know if this pertains to what you are seeing.

I manually report worms and mis-configured virus scanners.

My reports are always plain text, and for the virus scanners, I return their content pasted inline with out quoting.

The MIME filters on many systems incorrectly parse that part of the message as an attachment and either reject it or through it into quarantine.

MIME is an OPTION, and unless the headers of a message say it is in a MIME format, the body should not be parsed as if it contained MIME content.

Many MIME parsers do not pay attention to the headers, and will look for apparent MIME constructs in the message and try to interpret them. The famous "begin " bug is an example of this.

Also a few mail servers that I know of will reject some or all MIME content, as the owners have determined that it is spam.

So spammers will put incorrect MIME in side their spam to get around the content filtering that looks for MIME headers to determine how to analyze the content.

It is likely that it is not he spamcop messages that are not mime compliant, but the sample spam inside them is not, and that is what is triggering your check..

Some mail product vendors appear to want to force an end to plain-text e-mail, and are trying to work things in such a way to make sending plain-text mail difficult, and word their documentation in such a way to indicate that anything other than MIME has been depreciated.

-John

Personal Opinion Only

[jcrm]

From further reading I've done, it would appear that most automatic mailers are not MIME compliant at this point in time.

"software for windows" has got nothing to do with it...

... but standards do.

http://www.ietf.org/rfc/rfc2045.txt

rfc2821 doesn't seem to mention the requirement for rfc2045 headers, so in 7 bit clean messages with line lengths of less than 1000 characters you need not use it.

What gain do you/pegasus perceive from only accepting rfc2045 messages?

Personally I'd be glad to see MIME discarded completely, but then I can easily drop a file on a server and send someone a URL