[Bug ?] Ongeldige mail headers in alle react mail.

[Tomsworld]

Na een paar dagen zoeken waarom ik geen mailtjes van het forum aankreeg, geen passwoord mails, geen mails vanuit de admin eindelijk de oorzaak gevonden:

code:

Subject: GoT - Je bent een lul
Mime-Version: 1.0
From:

veroorzaakt op mijn mailserver (qmail met default qmail-scanner voor):

code:

A policy-violation was found in an Email message you sent. 
This Email scanner intercepted it and stopped the entire message reaching its destination. 

The policy-violation was reported to be: 

Disallowed MIME Content-Type found - not valid email

Wat zou beteken:

If you searched qmail-scanner-queue.pl, you'd see that "Disallowed MIME
Content" only shows up once. It means someone sent a mail message that:

a> claims to be MIME (by the presence of a "MIME-Version" header)
b> has a "Content-Type" header that is NOT in the RFC-prescribed format
of "XXX/YYY" (e.g. "text/plain")

As such Qmail-Scanner tags it as broken and quarantines it.

Sounds like a broken mailer in action to me...

En dan heb ik even rondgekeken en idd alle andere mails komen door:
bv mail van de fp

code:

X-Priority: 3
X-Mailer: Tweakers.net mailbotje / PHP v.4.4.4
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-15"

Het lijkt erop dat je als je een mime header zet deze liefst in hoofdletters staat en er minstens een Content-Type bij moet:

code:

MIME-Version: 1.0
Content-type: text/plain
Content-Transfer-Encoding: 8bit

[Osiris]

No offence hoor, maar je zegt iets over hoofdletters bij de mime-header en iets over een missende content-type-header. In jouw laatste voorbeeld is de mime-header exact hetzelfde als in de 'foute' en is het enige verschil van de content-type-header de charset, iets wat geen probleem op zou moeten leveren

Hmm, nu zie ik dat je jouw content-type-header met een lowecase 't' hebt, maar iets zegt me dat je dat niet bedoelt

Om een of andere reden weigert T.net mij een mailtje te sturen over m'n "nieuwe" password trouwens, dus checken kan ik 't niet

moto-moi to the rescue met uitleg Blijft 't een feit dat React m'n password-reset-aanvraag niet verstuurt

Heb em, nu is m'n post helemaal overbodig

[ Voor 42% gewijzigd door Osiris op 14-10-2006 01:04 ]

[crisp]

Voor zover ik kan beoordelen nav rfc2045 is Content-Type optional en indien niet aanwezig zou de UA 'Content-type: text/plain; charset=us-ascii' moeten aannemen. Verder zijn fieldnames in headers niet case-sensitive (zie rfc822)

[Verwijderd]

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

5.2. Content-Type Defaults

Default RFC 822 messages without a MIME Content-Type header are taken
by this protocol to be plain text in the US-ASCII character set,
which can be explicitly specified as:

code:

Content-type: text/plain; charset=us-ascii

This default is assumed if no Content-Type header field is specified.
It is also recommend that this default be assumed when a
syntactically invalid Content-Type header field is encountered. In
the presence of a MIME-Version header field and the absence of any
Content-Type header field, a receiving User Agent can also assume
that plain US-ASCII text was the sender's intent. Plain US-ASCII
text may still be assumed in the absence of a MIME-Version or the
presence of an syntactically invalid Content-Type header field, but
the sender's intent might have been otherwise.

Over de case sensitivity heb ik ik RFC 2045 niets expliciets gevonden. De BNF meuk lijkt erop te wijzen dat de header namen in 2045 case sensitive zijn. Maar in 822 wordt expliciet gezegd dat het niet zo is, en 2045 zegt redelijk backward compatible te zijn. Wat een onduidelijkheid weer.

Om het netjes te houden zou ik de exacte spelling uit RFC 2045 overnemen, dan moet het sowieso altijd goed gaan. Neemt niet weg dat het wat mij betreft redelijke onzin is als de header namen case sensitive zouden zijn.

[Tomsworld]

Zover was ik ook geraakt in de rfc's, ik kan het nu wel uitzetten, alhoewel ik het raar vindt dat dit de eerste false positives ooit zijn en er is toch al heel wat mail gegaan door die server.

Ik wou het maar melden omdat er misschien ooit nog users komen die mail hebben die door een qmail icm met qmail-scanner server afgehandeld wordt en deze vertonen default dit (misschien foute) gedrag.

[crisp]

Ik denk ook dat het een kleine moeite is voor Parse om gewoon even een Content-type header toe te voegen, maar het lijkt me ook geen kwaad kunnen om de makers van de qmail-scanner er op te wijzen dat ze in dit geval onterecht mails als 'broken' markeren

[Tomsworld]

Inderdaad ga ik ook ff doen, ik ben wel aan het migreren binnen een paar maandjes (qmail eruit, postfix erin).

En in 2003 stond er geen mime regel in de react mails het is dus is ergens ingevoerd.

[crisp]

Tomsworld schreef op zaterdag 14 oktober 2006 @ 21:24:
En in 2003 stond er geen mime regel in de react mails het is dus is ergens ingevoerd.

Dat is niet onwaarschijnlijk

[crisp]

Ik heb een fix voorbij zien komen in SVN