ietf-822
[Top] [All Lists]

RE: I-D Recommendations for Automatic Responses to Electronic Mail

2002-06-06 11:22:03

Dan,

thanks for your comments. I agree with most of them.

In 1.1, the description of Group Responders should include an
example of a service address (support(_at_)example(_dot_)com), which you
mentioned in some email threads but isn't described directly
here in the I-D itself.  The virus scanner is one example,
but the autoresponder for service addresses is a better (and
more common) example.

I'm not sure what you mean here.  How is an autoresponder for
service addresses an example of a Group Responder, unless
it answers on behalf of several different recipients in a
way over which those recipients don't have control?

(or do I need to tweak my definition of Group Repsonder?
IMHO, recipient control over the response is the primary
thing that distinguishes Group from Personal responses)

My employer, and many others, have both externally-visible
addresses which run scripts that assign a case number
to your email and usually attempt to route the message (based
on its content or key words) into a problem-tracking system
or routes the message via email to groups of technical-
support or product-information specialists.  For example,
if you email Canon and include in the message body the word
Camera, your email will be routed to product-information
specialists who know Canon's photography products.  Instead,
if you had included the word "copier", your message would
have been routed differently.

In both cases, however, you send your message to info(_at_)canon(_dot_)com
and receive back one message indicating a tracking number,
a phone number you can call to check on your question (if so
desired), and an indication that 'your message has been routed
to the appropriate group to respond to your question'.

Many companys utilize autoresponders for their support@
and info@ addresses.

The recipients of the messages (which are routed and forwarded
by the autoresponders, typically with the tracking number
now included in the Subject line for easy coorelation by
the same autoresponder software), have no control over the
autoresponder -- thus, it's a "Group Autoresponder" per your
definition.

I'm only asking that you include an example of the above in
addition to your virus-scanner example.

Section 2.2 mentions multipart/alternative for multi-language
response, but also says multiple charsets?

multiple language often requires multiple charsets, at least until
the whole world adopts UTF-8 (I'm not holding my breath.)

Yes, they often do, but as written it's confusing.

OTOH, if you can put text in several languages in a single body part,
multipart/alternative might be overkill.  current UAs don't seem to be
good at handling language differences in mp/alternative anyway.

Agreed.

But I can try to clarify the text.

Thanks.

By the way, I have noticed some autoresponders don't decode
RFC2047-encoded subject lines correctly when they include
the Subject of the "subject message" in the body of the
response.

hmmm.

Subject: Auto-Re: =?encoded-word?=

is perfectly valid (as long as there's a space after "Auto-Re:")

No, I mean the Subject Message is:

  Return-Path: <dwing(_at_)cisco(_dot_)com>
  From: dwing(_at_)cisco(_dot_)com
  Subject: =?encoded-word?=
  To: moore(_at_)cs(_dot_)utk(_dot_)edu

  Hi, Keith.
  -dan
  <END OF MESSAGE>

and your autoresponder responds with:

  Return-Path: <moore(_at_)cs(_dot_)utk(_dot_)edu>
  To: dwing(_at_)cisco(_dot_)com
  From: moore(_at_)cs(_dot_)utk(_dot_)edu
  Subject: Keith is out of the office
  auto-submitted: auto-replied

  Keith has received your message with subject:
    =?encoded-word?=
  and will read it when he returns.

  <END OF MESSAGE>

when it should do something different with the Subject -- either it needs to use
the same charset as the RFC2047-encoded subject (unlikely), or it should omit
the Subject entirely if the Subject's charset isn't the same charset as the
autoreply.

Section 3 says:

    An automatic responder MUST NOT send a response
    for every message received.

This requirement will break all mailing list software
(majordomo, LISTSERV, etc.), as they're supposed to
send a response for every message received.

are they really supposed to send a response to spam or viruses?
that's why I say that in practice every responder needs some
filtering to make sure the input is valid.

Then:

    An automatic responder MUST include mechanisms which
    prevent or reduce the effects of responding to malicious
    use or spam.  Such mechanisms ard described in this
    section.

Later, it says:

     Responders SHOULD check the destination
     address for validity before generating the
     response, to avoid cluttering up the local
     mail queues with messages that cannot be
     delivered or are unlikely to be useful.

I don't quite think this responsibility falls directly
on the responder, but rather on the local mail system
to validate RCPT TO addresses for syntactic validity
before accepting the message from an application such
as mail or an autoresponder.

the point is to avoid burdening the mail system with things
it shouldn't have to deal with.  early detection wins.

the downside, I suppose, is that by giving this burden
to the responder then the risk is greater that at least
one component will impose inappropriate restrictions - like
those web sites that won't let me type in 
moore+frob(_at_)cs(_dot_)utk(_dot_)edu
as an email address because they think it's invalid.

I'll think about this some more.

Where that detection/validation takes place is quite site-
specific.  The responder could be overly-anal in its interpretation
of that requirement, for example, and might want to try connecting
to port 25 of the MX record for the domain, when such outgoing
connections aren't permitted by the site's security policy.  Thus
the connection will fail, the autoresponder will decide the
address isn't valid, and won't submit it to the local mailer.
I agree this is an extreme example, but others are equally
valid (bang and percent-hack addresses, for example, could be
rejected by the autoresponder unnecessarily.  Likewise, bang
and percent-hack could be validated by the responder but may
be undeliverable by the site's mailer due to purposeful configuration
to prevent such addressing in another misguided attempt to block
spam).

As pointed out on
the mailing list, many group responders currently use
Reply-To because in many UAs, From isn't rewritable
(and MAIL FROM is even more unlikely to be rewritable),
and users might have legitimate reasons to specify
a different Reply-To, and users like that group
autoresponders use that specific Reply-To.  I know
back in days that BITNET hosts had filestores, I
liked the ability to use Reply-To to direct file
requests to another mailbox for example.

I understand that such UAs exist (though I don't think
they're nearly so common anymore).    I'm not sure how
much we should do to try to accomodate them.  A UA that
can't set From but can set Reply-To just seems fundamentally
broken to me, though I'll grant that RFC 822 never said
"UAs MUST allow users to set the From field".

It's clearly wrong for a Personal or Group responder to
use Reply-To.  It *might* be reasonable for a Service
repsonder to use Reply-To, because presumably the
sender expects an automatic response from a Service
responder and has set Reply-To.  I tried to leave more
wiggle room for Service responders than Personal or
Group responders in this regard.

Okay.

Thanks,
-d



<Prev in Thread] Current Thread [Next in Thread>