On Wed, Dec 04, 2002 at 12:00:48PM +0000, Philip Hazel wrote:
> I'm afraid it *does* change the API. When the return code is "accept",
> it is defined that the value of the return string is placed in the
> $local_scan_data variable, for use by routers and transports. I'm sure
> people are using this.
Ok, let me see if I understand.
- If you return 4xx or 5xx, *return_text is already used to print the
error message back to the sender, and the value is always made
available to exim.conf in $local_scan_data
- In the case of 2xx, *return_text also gets sent back to
$local_scan_data, but doesn't get used to print next to the 2xx code
in the response to the sender (which honestly, was unexpected for me
when I first started using the local_scan API
- you are concerned that someone might be assigning values to
return_text which in the 4xx and 5xx cases would be displayed in the
SMTP conversation, but that people are relying on not being displayed
in the 2xx case
If I did summarize this correctly, then I understand now. Honestly, I'd
be very surprized if someone is actually doing the above and relying on
return_text not being printed in the SMTP ack.
I don't think anyone actually replied that making return_text visible in
the SMTP ok would break anything for them, and I think the ods of anyone
at all actually relying on this the way it is right now are not high,
but indeed, it is a small change of behavior for the API, I stand
corrected.
> That is why I was trying to think of some semi-compatible way of
> splitting one string into two - part for $local_scan_data, and part for
> the return message. But this cannot be done tidily.
Right, that sounded kind of ugly
> Simply returning the string would be highly incompatible, and might
> expose private data.
If it is indeed being used as such by someone
On Wed, Dec 04, 2002 at 01:07:30PM +0100, Nico Erfurth wrote:
> Hmmm, can't we do it with a global string that's published in
> local_scan.h? (I know, that's not clean, but it won't break everything).
>
> something like
> static uschar *smtp_return_text = NULL;
That's the next option, I was going to suggest the same thing.
That said, I don't need this feature near as badly as being able to use
exim's smtp_sprintf and get back an error code if the write fails
(currently, writes are unchecked in exim). This prevents me from
properly supporting a TLS connection and I have to do the following
monstruosity instead:
spamstatus=string_sprintf("%s trigger=%.1f", spamstatus, SAteergrube);
log_write(0, LOG_MAIN, "SA: local_scan will teergrube the sender for %d secs: %s (scanned in %d/%d secs). %s", SAteergrubetime, spamstatus, scantime, fulltime, mailinfo);
/* Exim might want to stop us if we run for too long, but that's
* exactly what we're trying to do, so let's override that */
alarm(0);
for (i=0;i<SAteergrubetime/10;i++)
{
char *str;
/* Unfortunately, we can't use exim's smtp_printf because it
* doesn't return an error code if the write gets an EPIPE.
* So, we write ourselves, but this won't work if you have a
* TLS connection opened (that said, if you are teergrubing
* a TLS connection, it's probably a relay host, not a
* spammer, and in this case you should not teergrube a
* friendly relay, so basically we should be ok).
* If you do teergrube an SSL connection with the current
* code, you will break it, but that's acceptable */
str=string_sprintf("451- wait for more output (%s)\r\n", spamstatus);
/* We cheat, stderr happens to go to the SMTP socket */
ret=write(2, str, strlen(str));
if (ret < 0)
{
log_write(0, LOG_MAIN, "SA: Interrupting Teergrube, remote side closed the connection after about %d secs", i*10);
/* You wouldn't really want to show this to the remote
* sender by now, but exim doesn't let you log to LOG_REJECT
* without dumping the wholes message, so we use return_text
* for logging this */
*return_text=string_sprintf("Remote side closed the connection after about %d secs of teergrube (%s)", i*10, spamstatus);
return LOCAL_SCAN_TEMPREJECT;
}
sleep(10);
}
On Wed, Dec 04, 2002 at 09:39:57AM -0500, Tabor J. Wells wrote:
> I'll defer to Philip regarding whether or not it changes the API.
It does, slightly, I was mistaken. I'm still not certain that anyone is
relying on the current behavior though.
> custom 2xx message, and then junking the message. Why not just reject it
> at the end of DATA if the concern is that the sender know the reason it
> didn't go to the intended recipient?
There are few reasons to do it, but one is for a spamtrap where you want
automatted spam robots to get the 2xx they want so that they don't
unsubscribe you, but at the same time you might want to return a message
about what you've really done either for debugging or helping remote
admins if their message got marked as spam and devnulled by mistake.
Yes, this is a very marginal example, I realize that.
Let's just say I saw some potential use in it, and I was surprized at
the inconsistent handling of return_text depending on the return code of
local_scan
But no, I won't fight teeth and nails about that one, there are much
lower hanging fruits to take care of (see example above)
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@??? for PGP key
