On Wed, 23 Nov 2011, [email protected] wrote:
> On 23/11/11 14:27, Always Learning wrote:
>
> >> Yes, it is. You should never rely on the sender being able to see the
> >> rejection message that you supplied.
> >
> > How does one convey anything meaningful to the sender ? Apart from
> > composing a separate email to them ? And can that be done in ACL RCPT ?
>
> The only way of doing that reliably, is to compose a separate email.
> Although if you do that, you need to make sure you do appropriate sender
> verification (DKIM or SPF) so that you don't generate backscatter.
>
> It's pretty crap really, but this is the situation we find ourselves in.
I agree that I've seen systems that:
1. return all of the multi-line refusal message to the sender (yay!);
2. return only the first line of the multi-line refusal message to the
sender;
3. return only the last line of the multi-line refusal message to the
sender;
4. return none of the lines of the multi-line refusal message to the
sender, but instead just make one up that bears no relation to the actual
reason for refusal ("No such address"), and possibly bury other useful way
down in a section referred to the attention of the "system administrator"
or some such (Exchange);
5. return nothing to the user and let them believe the message was
delivered successfully (Orange/fsnet/freeserve, yes this means you).
Not sure I would go to any effort of trying to send a separate mail for
the error, with all the dangers that involves. Seems to me the likelihood
of the sender domain having half-decent features like DKIM and SPF is
pretty small if the sender system is fundamentally broken like this. I'm
happy that the intersection is tiny enough not to make it worthwhile
against the risks, and we just live with the vague reports ("my friend
sent me an email and it didn't arrive. Why?"; "I sent an email and got an
error. I know the address is right. Please help").
I generally found that case 3. was common enough, so in that one last line
I put in enough information so that I could at least find the transaction
in my own logs, should that one line wind its way back to me in some
query. From my config, the last line of the refusal message is usually
from this macro:
TRACEINFO = Trace: SHORTHOSTNAME \
${if def:message_exim_id {$message_exim_id} \
{(pre-data:$acl_m10)}} \
$tod_log
which identifies the host, the time, and message ID information (pre-data
$acl_m10 is a pseudo-message ID that I generate before the data phase
creates the real one). Also helps track the message in the logs when you
get the full error questioned too, of course.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK
The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
