Re: [exim] re spamming

* Ian FREISLICH wrote (22/11/06 11:58):
> John Robinson wrote:
>> On 22/11/2006 10:37, Deepak Kapoor wrote:
>>> On 11/22/06, Ian FREISLICH <if@???> wrote:
>> [...]
>>>> No, for some reason exim doesn't log the size of rejected mails,
>> Because usually it can't, it hasn't received the email yet.
>
> I wasn't clear: For some reason exim doesn't log the size of
> rejected mails when the message is rejected after data by an ACL.
>
> Also:
>
> When the client (MUA or transmitting MTA) times out the connection
> early, exim doesn't log the size recieved so far and then discarded.
> I've seen this happen quite often as well.
>
>>>> For cases where the rejection may involve significant bandwidth.
>> This would be rare and would depend on having a specialised
>> configuration which does reject after DATA and doesn't log *anything*
>> from the sound of what Deepak's saying.
>
> It's rare enough to be a significant portion of some of our clients'
> bandwidth. This specialised configuration you talk of is not in
> as wide disuse as I think you suspect it is.
>
> There are many cases where the SMTP connection uses a non-trivial
> amount of bandwidth, but no logs to this effect are produced. The
> same goes for most other services.

The size might not be logged, but the fact that something happened would
be logged, wouldn't it? My understanding (well, my guess anyway) was
that nothing at all was logged in the original example. Which is why I
thought that something other than exim might be responsible for the
bandwidth. But since I don't know what is actually being measured
(incoming, outgoing, what port, where and how the measurement is taken),
this is conjecture.

My assumption (based on the quote "i have seen that his
bandwidth goes as high as 150 MB in one hour due to email but if you
check the /var/log/exim/mainlog then you'll see thet the user has just
sent five to six emails") is that the user is responsible for a lot of
outgoing port 25 traffic, and that it's being sent by a process other
than exim.

Chris