On my last mail, how to apply sieve's reject towards a mail
envelope, containing more than 1 recipients, the very right approach
is to use PRDR - Per Recipient Delivery Response,
http://www.ietf.org/internet-drafts/draft-hall-prdr-00.txt.
As I have stated previously, that remains to be seen. In the best possible case
PRDR deployment is going to be very challening. Worst case it won't even see
the light of day as a standard, let alone see any deployment whatsoever.
The next
option is to do what Arnt suggested (first RCPT TO: -> 250 OK,
consequent RCPT TO: -> 4xx temporary error).
No, the next option is to accept the message and send back nondelivery
notifications for the recipients who are determined to have failed after the
message has been transferred. 4xy responses to all but the first recipient is
an extremely drastic measure with all sorts of potentially very serious side
effects. Again, all of this has been discussed previously.
And now I would like to ask for your opinion about providing a
standard way to send vacations over smtp and reflecting this standard
way on the design of sieve-vacation.
Although it has not yet been published as an RFC due to normative dependencies
on other drafts, sieve vacation is already approved as a proposed standard. You
are well over a year too late to make any sort of major change to it.
The idea is similar to DNS: when the recipient will not get the
message (immediately), an error message is sent - first during the
SMTP dialog, later in form of bounce. The problem with the bounces is
that they might end in spamtrap, blacklisting the server, which sent
them. Out office messages are a kind of bounces, and moreover they
shall not be sent in response to mails coming from , -owner@,
listserv@, etc, and shall go to the one who actually sent the message,
not the one that are in the envelope's From: (read faked by spammer).
In this similar case the reject approach was extended to react
even during SMTP dialog, thus abolishing the (non-existent, but cool)
possibility to generate MIME/html messag bounces for rejected mails
already in sieve.
What about inventing a new SMTP extension, new response SMTP code
and giving back as response during the SMTP dialog, that the recipient
is on holiday? In this way the sender's MUA will have a standard way
to interpret the message, incl. translation to the local language.
I don't see how that could possibly work. At most you could get the the fact
that the message isn't going to be seen for some period of time out of a
structure response of some kind. However, the nature of vacation responses is
that they necessarily contain textual information about why the recipient is
unavailable, who to contact as an alternative, and various other critical stuff
that cannot possibly be coded in a structured way.
So like it or not, useful localization of vacation responses has to be done by
the person or agent generating the response. This is sharp contrast to
nondelivery notifications, where the semantics associated with the reason for
nondelivery can be categorized to some extent, making remote translation
workable in most cases.
Moreover, existing vacation mechanisms, including but not limited to sieve
vacation, already provide fairly elaborate internationalization and
localization facilities. For example, I can easily code a sieve to perform a
test on the original message and send, say, a response in English to one set of
users and a response in Spanish to another. It is simply not possible to
duplicate these facilities, many of which depend on examination of the content
of the original message, in a mechanism that operates at RCPT TO time. So PRDR
or something similar is a necessary prerequisite for anything along these
lines.
Even worse, since SMTP responses are currently limited to US-ASCII, in order
for this to work at all well it will depend on the deployment of an SMTP
extension.
But let's suppose all the necessary prerequisites for this extension are
present, making it possible for a post-DATA response to present a properly
localized vacation response. Now what? In many cases this will be happening on
a relay hop, not a submission hop. So now an MTA has this information, not an
MUA. The only way the MTA can provide this information to the user is to put it
in a message and send it, and the minute it does that you've just reintroduced
all the problems with notification filtering this mechanism was intended to
avoid.
So what you're talking about here is an extension that necessarily depends on
at least two other extensions, neither of which are even standardized at this
point and which may never be standadized, let alone deployed. And even if all
this stuff deploys it doesn't really solve the original problem in many cases.
I conclude that this would require a huge deployment effort with marginal
benefits at best. In other words, IMO this is a complete nonstarter.
Ned