[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: message size limitations
On Wed, Oct 02, 2002 at 05:27:08PM +0200, Marek Kowal wrote:
> Hi there,
> I would like to vary maximum message size allowed by the smtp server based
> on the login of the sender from envelope address. The problem is, this quota
The "login" you can get by doing AUTH, the MAIL FROM carried address
makes no guarantee of anything.
Once upon a time I did consider adding code to be able to parametrize
the SIZE-limit value by source IP address. (E.g. your dialup pools..)
Oh.. There is even code, lots of it..
The documentation is -- lacking. Fix into doc/guides/smtp-policy,
and pasting here relevant passage:
Who can use us as outbound relay.
for listing those senders (networks) we
absolutely trust. Additionally you may give
(at the same line) some attributes as parameters
for this key entry:
The first pair will accept any source address,
and any recipient addresses that are fed to
The second will verify the source IP-address,
but after that it will accept any recipient
The third pair sets EHLO-reported "SIZE nn"
parameter to be limited to 30 million bytes.
(Or to global definition, if that is in range
of 1 thru 'nn'-1.)
The parameter usage is purely advisorial. It is used when formulating
the EHLO response, not when checking e.g. MAIL FROM:<..> SIZE=
> is advertised by server after EHLO command, before MAIL FROM: command. Of
> course, I could advertise some big number there and refuse to process mail
> after "." from DATA command, but this will make users angry - first they
> will send huge mail over slow modem link for several minutes, and then they
> will be informed, that we are sorry etc... And the so called "user's
> positive experience" is an important issue for us and we'd rather not
> proceed in this direction.
> Is there any way to force/advise client to send actual message size intended
> to be transmitted before DATA command, but after MAIL FROM: <>?
IF the client looks for EHLO reported SIZE value, then this technique can
be used to control the thing. If not.. A code change is then (perhaps)
Of course the OE won't explain the remote system refusal in any
understandable way, which will cause your users to grieve more..
> Obviously, my main concern are Outlook Express clients, as they tend to be
> in biggest abundance out there in the real world ;-) Such cooperation from
> other relays would be feasible, but is not cruicial - i.e. I will loose some
> bandwidth, but at least the user will not wait, just the other server.
... however that is the pickle we all are in, OE is moron.
> Let me know, if you have any advices or experiences with that issue.
/Matti Aarnio <firstname.lastname@example.org>
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to email@example.com