URL:
<http://gna.org/bugs/?func=detailitem&item_id=2030>
Summary: Undeliverable mail, invalid characters in header
Project: Savane
Submitted by: yeupou
Submitted on: lun 28.02.2005 � 11:49
Category: Web Frontend
Severity: 5 - Blocker
Priority: B - Low
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Release:
Planned Release:
_______________________________________________________
Details:
What should we do about that:
-----------------
INVALID HEADER (INVALID CHARACTERS OR SPACE GAP)
Non-encoded 8-bit data (char E9 hex) in message header 'Subject': Subject:
Gna! Cr\351ation d'un nouv...
This nondelivery report was generated by the amavisd-new program
at host indyvss3. Our internal reference code for your message
is 16740-01-30.
WHAT IS AN INVALID CHARACTER IN MAIL HEADER?
The RFC 2822 standard specifies rules for forming internet messages.
It does not allow the use of characters with codes above 127 to be used
directly (non-encoded) in mail header (it also prohibits NUL and bare CR).
If characters (e.g. with diacritics) from ISO Latin or other alphabets
need to be included in the header, these characters need to be properly
encoded according to RFC 2047. This encoding is often done transparently
by mail reader (MUA), but if automatic encoding is not available (e.g.
by some older MUA) it is the user's responsibility to avoid the use
of such characters in mail header, or to encode them manually. Typically
the offending header fields in this category are 'Subject',
'Organization',
and comment fields in e-mail addresses of the 'From', 'To' and 'Cc'.
Sometimes such invalid header fields are inserted automatically
by some MUA, MTA, content checker, or other mail handling service.
If this is the case, that service needs to be fixed or properly
configured.
Typically the offending header fields in this category are 'Date',
'Received', 'X-Mailer', 'X-Priority', 'X-Scanned', etc.
If you don't know how to fix or avoid the problem, please report it
to _your_ postmaster or system manager.
-----------------
It is a pedantic RFC that lost touch with reality or something we should care
about and fix?
The pain with spam is the fact that it forces people to implement whatever RFC
between spam robots turns out to disregard them all.
And people often confuse RFC with "rules" that everyone must complies with,
like the content of this mail shows. But indeed, anyone is entitled to refuse
communicating with someone that blatantly ignores RFC, like mail.gna.org does
in some cases.
I guess we could improve sendmail_mail() so it encodes properly every
headers.
_______________________________________________________
This item URL is:
<http://gna.org/bugs/?func=detailitem&item_id=2030>
_______________________________________________
Message post� via/par Gna!
http://gna.org/
_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev
