ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] NEW ISSUE: NAKED CR & LF issues with bodycanonicalization

2006-07-16 23:43:26

----- Original Message -----
From: "John L" <johnl(_at_)iecc(_dot_)com>
To: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>

I have never come across an application that depended on naked CR or LF
being passed through SMTP.

Is QMAIL strickly a SMTP to SMTP transport system?

Does QMAIL only accept feeds from SMTP or does it support the eyeballing of
queued folders and feeds from integrated or external packages or processors?

If so, what formats can it accept?

Did QMAIL evolved from UUCP/SLIP processing with support for unix flavor LF
eol storage formats? or MAC based feeds with its CR eol storage formats?

I saw you wrote QMAIL will reject LF eol SMTP feeds.  I was surprise to read
this.  Sounds odd.  Is that an follow strict 2822 option or something in
qmail?

Our Wildcat! List Server has the option to create its distribution and
tranport it via SMTP or UUCP.  Many of our operators will choose the UUCP
method because they want to isolate their LS machine to non-SMTP duties.

In SMTP mode, it sends directly to some defined SMTP host(s). In UUCP mode,
it creates and queues standard *.DAT/*.XQT/*.CMD files with the expectation
that some other processor will pick up this unix flavor storaged files and
do something with them.

In the old days, that would been some UUCP/SLIP gate.

Today, it could be a SMTP router/server eyeballing some outgoing queue feed.
An SMTP server with such long term support, will handle all types of feeds,
wither it was comeing directly from a SMTP client or queues for routing from
another source.

Similar, our gate software works with many formats and also centralizes
itself with standard UUCP style files between the online HOST and the SMTP
server.

However, our SMTP server will ALWAY send out conpliant CRLF lines.  On the
SMTP receive side, it will follow RFC 2821 requirements for:

   - Transformation of initial double dots to single dots,
   - Check for the DATA delimiter <CRLF>.<CRLF>

and everything else is received as is and typically left alone because of a
historical and common mail designer ethical tradition to avoid the design
taboo of "thou shall not screw around with mail content."

Anyway,

-1 for any idea that touches base with the score + plus years and old
tradition of not tampering with mail content - not even for DKIM.

I believe the better solution is Michael's suggestion of just dealing with
the DKIM feed.  No need to alter content permanently unless the WORLD
accepts and adopts this fundamental change in mail design mindset.

PS: No need to tell me that software already change content. To me, they are
the ones that partly responsible for the mess and disrespect in mail
intrigity issues.   The problem isn't really SMTP or the mail system, it is
DKIM, it is the one that needs to fit with the system, not the other way
around.  Thats the pragmatic and conservative approach to maximimize its
adoption and minimize acceptance barriers.

---
HLS














_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html