Re: [Exim] local_scan() addition: views sought

Top Page
Delete this message
Reply to this message
Author: Marc MERLIN
Date:  
To: Philip Hazel, Nico Erfurth, Tabor J. Wells
CC: exim-users
Subject: Re: [Exim] local_scan() addition: views sought
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