True, no spam I've seen was big enough to be considered "too big". I guess
a more relevant issue would be clueless users who think that sending their
10mb adobe acrobat brochure via email is a smart thing to do, and all those
amateur artists who just *have* to send their 50mb high res picture to a
client via email! *smack smack smack*
I don't know if any MTAs actually use the SIZE command as an accurate count
for message size, however exim does apparently use it to check disk space:
"The amount of disk space available is checked whenever SIZE is received on
a MAIL command, independently of whether message_size_limit or
check_spool_space is configured, unless smtp_check_spool_space is set false.
A temporary error is given if there is not enough space. If
check_spool_space is set, the check is for that amount of space plus the
value given with SIZE, that is, it checks that the addition of the incoming
message will not reduce the space below the threshold."
I don't know if that could cause any problems, but I guess there is a chance
if you're critically low on spool space, and someone misrepresents the
actual message size to be much smaller than the message really is once sent
across in the DATA stage. No idea if SIZE is also used elsewhere, and/or if
other mail servers use it at all (I thought I read somewhere that exim will
reject a message if it sends more data than reported with the SIZE command -
no idea where I thought I saw that though).
Eli.
-----Original Message-----
From: Wakko Warner [
mailto:wakko@animx.eu.org]
Sent: Wednesday, December 31, 2003 3:45 PM
To: Eli
Cc: 'Exim User's Mailing List'
Subject: Re: [Exim] Any benefits to having exim use the SIZE command?
> Hm yes I guess that would be quite useful, however like you said most MUAs
> don't send the SIZE paramater, and I would really only see spammers or
> outside unknown users sending inbound messages that I would want to block
> due to message size - and if they don't specify SIZE, I'd have to wait
until
> DATA time to filter it out anyways.
How many spams you see that are large enough to be blocked by someone on
size alone?
> I was more wondering about its uses as exim acts as a client though -
since
> that's when exim uses SIZE itself. I was reading somewhere that if a
> message is modified enough to change it's size more than size_addition (in
> an smtp transport), exim won't know the proper size of the message - I'm
not
> sure if any of that is really what was written down though :P It concerns
> me though because if I have SpamAssasin running or something, and it tags
a
> message as spam and redoes the message, and then goes to deliver it, but
the
> user has forwarding enabled outbound, so exim handles it on it's smpt
> transport, I wouldn't want exim failing to send it since the message was
> rewritten by SA enough to throw off the SIZE value so much that it can't
> send it any more (if the remote smpt server supports SIZE that is).
I'd say in this case, just send the size that's known. As I understood it,
the size= on the mail from: line isn't to be trusted.
I could easily say "I have a 100kb message for you" and give you 10mb.
If anyone knows, at what point during the data phase would exim drop a
connection because of the message size? At some point it will have to be
dropped or aborted.
> -----Original Message-----
> From: Wakko Warner [mailto:wakko@animx.eu.org]
> Sent: Wednesday, December 31, 2003 12:20 PM
> To: Eli
> Cc: 'Exim User's Mailing List'
> Subject: Re: [Exim] Any benefits to having exim use the SIZE command?
>
> > I am wondering what, if any, benefits or added features or whatever are
> > gained by the additional use of the SIZE command/paramater in a MAIL
> > command?
> >
> > I ask because of all the different issues regarding size changes to
> messages
> > when the SIZE paramater is used, it almost seems like it would be
> generally
> > better to disable the use of SIZE altogether - but I wouldn't want to do
> > this if I lose other functionality.
>
> On the MUA side, some client's don't send it. One use I can see is for a
> server to refuse mail because the size is too big before wasting the
> bandwidth to send it.
>
> I setup the server at work to check this at mail and data time. At data
> time, the damage is already done (bandwidth wise and transfer time), but
it
> won't go further if it's too big (wasting more bandwidth/time/disk
> space/whatever)
>
> --
> Lab tests show that use of micro$oft causes cancer in lab animals
> ---
> [This E-mail scanned for viruses]
>
>
>
> ---
> [This E-mail scanned for viruses]
>
--
Lab tests show that use of micro$oft causes cancer in lab animals
---
[This E-mail scanned for viruses]
---
[This E-mail scanned for viruses]
