headers
Internet-Drafts | 3 Sep 16:15
Picon
Favicon

I-D ACTION:draft-moore-auto-email-response-03.txt,.ps,.pdf

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Recommendations for Automatic Responses to Electronic 
                          Mail
	Author(s)	: K. Moore
	Filename	: draft-moore-auto-email-response-03.txt,.ps,.pdf
	Pages		: 19
	Date		: 2003-9-3
	
This memo makes recommendations for software that automatically responds
to incoming electronic mail messages, including 'out of the office' or
'vacation' response generators, mail filtering software, email-based
information services, and other automatic responders.  The purpose of
these recommendations is to discourage undesirable behavior which is
caused or aggravated by such software, to encourage uniform behavior
(where appropriate) among automatic mail responders, and to clear up
some sources of confusion among implementors of automatic email
responders.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-moore-auto-email-response-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-moore-auto-email-response-03.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Moore | 3 Sep 16:39
Picon

changes in draft-moore-auto-email-response-03


I thank everyone who sent in comments.  Most changes requested were
simple wording changes, and I made most of these.  I appreciate the
effort it took to read this document carefully.

One person recommended I broaden the scope of this document to include
all automatically generated messages.  I decided not to do that, as I
thought it would dilute the effectivness of this document regarding
automatic responses.  Also, I didn't want to think about what additional
considerations there might be for automatically generated messages, and 
I think it's much more important to specify the behavior of automatic
responses.

Keith
--

-- 
During times of universal deceit, telling the truth becomes a
revolutionary act. 			-- George Orwell
Permalink | Reply | 0 comments |
headers
Dilip Menon | 8 Sep 18:26

SMTPPATH LEN to include '<' , '>' or not..


Hi,
I have a question regarding the maximum path length allowed in RCPT TO as
well as MAIL FROM.    RFC 2821 says, this limit is 256 bytes.
For e.g. if address is abc <at> def.com

So if we include the '<' and '>' characters,  will the total length be 258.
Or is it 256 inclusive of these characters?

Regards
Dilip Menon
Permalink | Reply | 1 comment |
headers
Arnt Gulbrandsen | 11 Sep 11:39
Picon
Favicon
Gravatar

Dealing with invalid UTF-8


Hi,

this morning I received a single-part mail message looking like this:

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
...
b2VrcmlzIEVuZ2luZWVyaW5nLCB0ZWNobmljYWwgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QNCgk+ 
IFt1bl1zdWJzY3JpYmU6IGh0dHA6Ly9saXN0cy5zb2VrcmlzLmNvbS9tYWlsbWFuL2xpc3RpbmZv
L3NvZWtyaXMtdGVjaA0KCT4NCgkNCgkNCg0K
_____________________________________________________________________
Soekris Engineering, technical discussion mailing list
[un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech

What's considered the best approach for dealing with something like 
this? ("Complain to GNU Mailman maintainer", while doubtless satisfying 
to some, is not my thing. I suppose I'm growing old.)

The RFC states that "Any characters outside of the base64 alphabet are 
to be ignored in base64-encoded data". That approach leads to appended 
garbage. Stopping decoding as soon as an illegal character is seen 
works in this case, but perhaps it might lead to truncation in other 
error cases?

Comments? Advice?

--Arnt
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Lilly | 11 Sep 13:37
Picon

Re: SMTPPATH LEN to include '<' , '>' or not..


Dilip Menon wrote:
> Hi,
> I have a question regarding the maximum path length allowed in RCPT TO as
> well as MAIL FROM.    RFC 2821 says, this limit is 256 bytes.
> For e.g. if address is abc <at> def.com
> 
> So if we include the '<' and '>' characters,  will the total length be 258.
> Or is it 256 inclusive of these characters?
> 
> Regards
> Dilip Menon

The exact wording in RFC 2821 is:

    path
       The maximum total length of a reverse-path or forward-path is 256
       characters (including the punctuation and element separators).

       Reverse-path = Path
       Forward-path = Path
       Path = "<" [ A-d-l ":" ] Mailbox ">"
       A-d-l = At-domain *( "," A-d-l )
             ; Note that this form, the so-called "source route",
             ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
             ; ignored.
       At-domain = "@" domain

The 256 character limit includes the angle brackets, @, local-part, domain(s),
(and in the case of deprecated source routes) commas and colon; those are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Baillie, Grant | 11 Sep 17:11
Picon
Favicon

Re: Dealing with invalid UTF-8


I have seen similarly misguided mailing list software which prepended  
an announcement to messages, regardless of the MIME structure. In many  
cases, because base64-decoding the announcement didn't correspond to an  
integral number of output bytes, the rest of the output ended up being  
bit-shifted. (Of course, the '=' padding at the end of the input wasn't  
correct, but it was too late for the decoder to recover).

One approach is to ignore lines which contain invalid base64  
characters, rather than just ignoring the invalid characters. That  
would work in these cases, at any rate; maybe other GIGO cases would  
behave worse, though.

--Grant

On Sep 11, 2003, at 2:39, Arnt Gulbrandsen wrote:

>
> Hi,
>
> this morning I received a single-part mail message looking like this:
>
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: base64
> ...
> b2VrcmlzIEVuZ2luZWVyaW5nLCB0ZWNobmljYWwgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3Q 
> NCgk+  
> IFt1bl1zdWJzY3JpYmU6IGh0dHA6Ly9saXN0cy5zb2VrcmlzLmNvbS9tYWlsbWFuL2xpc3R 
> pbmZv
> L3NvZWtyaXMtdGVjaA0KCT4NCgkNCgkNCg0K
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacob Palme | 25 Sep 18:10
Picon
Picon

Dual names, IDN and ASCII, in e-mail addresses?


IDN will soon be a practical reality, and non-ASCII
characters in e-mail addresses will probably soon be common
also in the localpart of the e-mail address.

This means that lots of people are going to have e-mail
addresses like Göran <at> Müller.de. And one of the main
problems with such names is that people in other countries
will have difficulty typing them. My guess is that many
Americans will have problem typing Göran <at> Müller.de, and
typing names in totally different alphabets like Greek,
Arabic, Cyrillic, Chinese, Korean, Japanese will be even
more difficult.

Because of this, many people will have business cards with
English information on one side, and information in their
own language on the other side. They will then also have
two e-mail addresses, since the ASCII version of IDN should
obviously be hidden from humans as much as possible.

They might then use their national e-mail address for
national mail, and their international e-mail address for
international mail. And certainly mail intended for one
region may get into another region, so that e-mail with
national names in some heading field will often get resent
internatinally.

One of the areas where MIME still, ten years after its
introduction, often fails is when people copy e-mail
messages into the bodies of new e-mail addresses. Quite
(Continue reading)

Permalink | Reply | 57 comments |
headers
Keith Moore | 25 Sep 22:00
Picon

Re: Dual names, IDN and ASCII, in e-mail addresses?


> One of the areas where MIME still, ten years after its
> introduction, often fails is when people copy e-mail
> messages into the bodies of new e-mail addresses. Quite
> often, you see text encoded according to the e-mail heading
> rules for non-ASCII characters in the bodies of such
> messages.

is that a failure of MIME or a failure to completely implement MIME?
how can the MIME spec (or any spec) solve a problem if implementors
pick and choose which parts they are going to implement?

> The conclusion of what I have written above is that there
> will maybe be a need to extend the existing e-mail
> standards, so that the e-mail address of especially From
> and Sender fields can be specified in a dual format, with
> both the national and the international (ASCII) name
> specified at the same time. 

not clear.  one sure way to cause problems is to provide two different
ways to specify the same thing, when those two things have any
possibility of diverging.
Permalink | Reply | 26 comments |
headers
Dave Crocker | 25 Sep 22:33

Re: Dual names, IDN and ASCII, in e-mail addresses?


Jacob,

Your concerns are timely and reasonable.  However I believe they are misguided.

Here is why:

JP> This means that lots of people are going to have e-mail
JP> addresses like Göran <at> Müller.de. And one of the main

In order to see such addresses in their "native" form, when they are encoded
using IDN, people will need email (or other) software that understands IDN.
Hence, they will be using software that is "internationalized" in the
necessary manner.

Others will see the ASCII version of the IDN string. Although these will be
ugly, they are completely compatible with existing email software. They can be
typed, and copied, etc., with no change to that software.

JP> problems with such names is that people in other countries
JP> will have difficulty typing them. My guess is that many
JP> Americans will have problem typing Göran <at> Müller.de, and
JP> typing names in totally different alphabets like Greek,
JP> Arabic, Cyrillic, Chinese, Korean, Japanese will be even
JP> more difficult.

People are already faced with this problem. It is not new to email. In fact,
it has almost nothing at all to do with email or IDN.

It has to do with user interface support for multiple character sets. I find
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Crocker | 25 Sep 22:32

Re: Dual names, IDN and ASCII, in e-mail addresses?


Jacob,

Your concerns are timely and reasonable.  However I believe they are misguided.

Here is why:

JP> This means that lots of people are going to have e-mail
JP> addresses like Göran <at> Müller.de. And one of the main

In order to see such addresses in their "native" form, when they are encoded
using IDN, people will need email (or other) software that understands IDN.
Hence, they will be using software that is "internationalized" in the
necessary manner.

Others will see the ASCII version of the IDN string. Although these will be
ugly, they are completely compatible with existing email software. They can be
typed, and copied, etc., with no change to that software.

JP> problems with such names is that people in other countries
JP> will have difficulty typing them. My guess is that many
JP> Americans will have problem typing Göran <at> Müller.de, and
JP> typing names in totally different alphabets like Greek,
JP> Arabic, Cyrillic, Chinese, Korean, Japanese will be even
JP> more difficult.

People are already faced with this problem. It is not new to email. In fact,
it has almost nothing at all to do with email or IDN.

It has to do with user interface support for multiple character sets. I find
(Continue reading)

Permalink | Reply | 19 comments |

Gmane