On Tue, Oct 28, 2003 at 12:44:08PM -0500, Keith Moore wrote:
Resent-From isn't handled at all. But it is important IMHO for
vacation programs not to answer to the From but Resent-From if
present.
[ ... ]
Indeed, about the only time I personally use resent is to forward a
message to a responder - either because the original message was
misdirected or because I want to respond with a form letter. Having the
responder respond to Resent-From would make resent entirely useless,
IMHO.
Ok, I just noticed that I probably abuse "bounce" for some years now ;-))
Each time I see an interesting document, announcement, etc. that I think
one of my colleagues or friends would find interesting, too, I bounce
it, if I think no additional comment is needed and I forward it if I
want to add comments.
A vacation type responder then answering to the From: surely will puzzle
the original sender. That's why I thought it would be more appropriate
to answer to Resent-From:
Well, you're simply wrong about that :)
That was the risk involved ;-)
To me, it makes little sense for the secretary to get DSNs and MDNs but
for the boss to get vacation notices. If the boss really wants to see
all of those responses, he can tell his secretary to configure the
secretary's MUA to use the boss's address in MAIL FROM.
I always try to use real life analogies.
The boss wants to send a letter. He tells the secretary to handle it.
The secretary puts the name of the boss on the paper and puts it in
a company envelope. If it's a return to sender the company gets it
and they look at the content and everything goes it's way. But the
other is more interesting now. The recipient is on vacation. His
secretary will open the letter, look at the content and she will write
back a latter to the "sender boss" telling that her boss in on vacation.
She will not address it to the senders' secreatry nor the senders
company. Right? ;-) Sending to MAIL FROM however would mean to send a
letter "Dear company, my boss is on vacation".
But as I agree with your statement a bit below I am convinced your
strategy is the way to go.
Even though the draft only says SHOULD NOT, IMHO responses should
*never* be sent to Sender. Sender is essentially a trace field, like
Received.
I totally agree.
Look, we can either tell MUAs and responders to guess which address they
should respond to (based on the phase of the moon, a random number
derived from a camera on a crystal ball, or whatever) or we can specify
a _protocol_ (wow!) that lets the sender tell the recipient where to
send certain kinds of mail. We've chosen to do the latter: MAIL FROM/
Return-path for bounces and automatic responses, From for the author(s),
Reply-To for wherever the author(s) think the likely response should
go, and To/Cc if the responder wants to include the original recipients
of the message (at least, those who were visible to the responder). And
while it's true that this set of categories is occasionally
insufficient, there is ample experience to indicate that lumping all of
the sender/author addresses onto From is much, much worse.
Agreed.
Besides I think you missed the point of the argument in section 4.
It's not that From/Reply-to are likely to contain incorrect information,
it's that they exist for very different purposes than to specify the
destination of automatic responses.
No I didn't really. It was more the
*> The Return-Path address is really the only one from the message header
*> that can be expected, as a matter of protocol, to be suitable for
*> automatic responses that were not anticipated by the sender.
at which I looked with my antispam hat on. But then, with spam, what is
realiable.
IMHO good behaving responders should use <>. Most responders don't
need to process bounces.
Valid point of view.
For some incident areas we create responder messages that tell the
customer that his messages has arrived and the incident number it
has been assigned.
With the increase of spam we utilize bounce-<incident_no>@... and
if the notificiation bounces we mark the incident as "has a high
probability of being spam" and it is moved to a low prio queue.
But again you're correct: Most responders don't need to process bounces.
If it's not too late I'd definitely would vote for a third keyword
in "5.1 Syntax" and have "antivirus-generated" added. This would be
a huge benefit if antivirus vendors would add that (and probably in
the comment area the name of the virus).
This doesn't really seem consistent with the purpose of auto-submitted.
Hmmmm ... I don't understand what the inconsistency is.
*> Other types of automatic response in common use include:
*> [ ... ]
*> - Various kinds of mail filters (including "virus scanners") which
*> act on behalf of a recipient to alter the content of messages
*> before forwarding them to that recipient, and issue responses in
*> the event a message is altered.
and virus scanners are mentioned also under "Group Responders".
So you seem to think they are responders and they auto submit messages,
even to whole groups of addresses.
- Another member of IRTF ASRG BCP mentioned:
> I'm a little concerned about the top of section 2
> "An automatic responder MUST NOT send a response for every
> message ..." while this is in a sense the whole thrust of the
> draft, I'd imagine that it sits badly with some applications -
> like forms of RPC over SMTP. Perhaps this is one to ask someone
> who knows SOAP etc?
So maybe a wording like
"An automatic responder MUST NOT _blindly_ send a response for
every message received."
can make that statement more clearer.
I understand your concern, but I guess I don't think your suggested text
is any clearer.
I didn't say it is perfect and it is surely easier for a native english
speaker to phrase it than for me, we only wanted to clarify out concerns
a bit.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"