postfix a "queue file size limit exceeded"

[Martin Mačok]

On Thu, Sep 14, 2000 at 02:33:11PM +0200, Martin Caslavsky wrote:
> Zkousim ted postfix a zcela necekane me prekvapil hlaskou "queue file
> size limit exceeded", chapu, ze nemuze do fronty ulozit nejakej vetsi
> mail, ale kterym prikazem se da povolit vetsi velikost? Nasel jsem
> jenom message_size_limit = 10240000, coz chapu jako 10 mega, pricemz
> inkriminovany mail mel sotva polovinu.

[postfix-19991231_pl08]

Ja jsem si na svem pocitaci nastavil zkusmo 
message_size_limit = 1024000 (cca 1MB - o jednu nulu mene nez default)
a chovalo se to presne podle ocekavani - pokud jsem poslal email, ktery
se s Base64 kodovanim vesel tesne pod 1024000 bytu, tak prosel. Pokud
ten email po prekodovani Base64 tesne (o par desitek bytu) prekonal
hranici 1024000, tak "size limit exceeded" ...

/* Poslal jsem si jako prilohu RPM-ko fetchmailu, ktere ma 724K, po
prekodovani Base64 ma 979K a postfix ma v logu hlasku 'size=1017819' a v
poradku email dorucil. Pokud jsem k nemu pripsal jeste asi 8K textu, tak
uz ho postfix odmitl ... */

(S hodnotou 10240000 jsem si moc nehral, ale pochybuju, ze by se to
chovalo jinak)

Sice jsem vam v podstate vubec neporadil, ale aspon vite, jak to funguje
u nekoho jineho :/

Nepouzilo se na ten vas email nejake prekodovani, ktere ten email
zvetsilo pres tech ~10MB ??? Neco jineho (vetsinou) o velikosti
attachmentu hlasi MUA a neco jineho je aktualni velikost emailu pro MTA.

Preji hezky den

P.S. Doufam, ze jsem prilis nerozzlobil zastance jednotek KiBi, MiBi
apod. :)

-- 
< Martin Mačok    .-=  martin.macok na underground.cz  =-.   < iso-8859-2 > 
  \\. http://kocour.ms.mff.cuni.cz/~macok/  http://underground.cz/ .//
    \\\..         `-=    t.r.u.s.t   n.0  o.n.e     =-'        ..///
------------- další část ---------------
A non-text attachment was scrubbed...
Name: [žádný popis není k dispozici]
Type: application/pgp-signature
Size: 232 bytes
Desc: [žádný popis není k dispozici]
URL: <http://www.linux.cz/pipermail/sendmail/attachments/20000916/31ae9f62/attachment.sig>