Philip Hazel wrote:
> The only place a message in an "accept" response is going to end up is
> the sending host's log, *if* it cares to log such text (Exim does). What
> Exim actually sends is the message id of the accepted message, so that
> it can be logged in case of a later query. Nothing gets back to the
> sending user, of course. That's why "message" does nothing on an
> "accept" statement. (It is documented that it only has an effect if
> access is denied.)
I see two uses for being able to send something when a message is accepted:
- one is to warn someone troubleshooting. They connect by hand from their mail
server to ours, and see something like '250 you are being throttled because your
host is on the DUL list, see
http://www.someblacklist.org/'
- the other is the less friendly plan to send (relatively) a lot of data back
per recipient. This would slow down spammers on slow lines a lot. Again, I'd
personally use this for you you didn't want to block but that you would not
expect to send a lot of mail to you. DUL hosts again.
Sending back a lot more data per recipient may be one way to make mass mailing
more expensive, but it won't be effective against spam I suppose.
It is not a bug, but having the possibility to add text to accept mesages could
be nice.
BTW I just did a dual language bounce message. If a bounce gets adressed to a
.nl domain a Dutch text is used. The nice flexibility of Exim shows.
I also send a small part of the message body back in the bounce, but the minimum
of 8K that exim wants to send is to big for me. I want bounces to be unusable
for sending spam. Thus I use $message_body to echo part of the message. It
containing spaces instead of newlines if not really a problem (keeps the compact
on screen), though it would be nice if it could be word wrapped.
Then again, the MUA will probably take care of that.
Thomas
