# [solved] Mail size problem with qmail/vpopmail/dovecot

## democles

Hy all,

My setup : local mailserver using qmail + vpopmail+dovecot+spamassassin+clamav. Mails from my mailbox@ISP are fetched using fetchmail and delivered to localhost (qmail)

versions:

netqmail-1.05-r8 use ssl

dovecot-1.1.7-r1 use ssl vpopmail

for my fetchmailconf : 

poll account@ISP proto pop3 user "xxxxxx" password "yyyyyyyy" is" user@homenet.be" here options forcecr

here what I get when fetchmail is fetching  /delivering mail  (fetchmail -f /etc/fetchmailrc -v -v)

fetchmail: forwarding to localhost  (

fetchmail: SMTP> MAIL FROM:<somebody@somedomain> SIZE=6433

fetchmail: SMTP< 250 ok

fetchmail: SMTP> RCPT TO:<myaccount@homenet.be>

fetchmail: SMTP< 250 ok

fetchmail: SMTP> DATA

fetchmail: SMTP< 354 go ahead

#***************.********************************.***************.******************.********fetchmail: message loging@isp:6 was not the expected length (6567 actual != 6433 expected)

fetchmail: SMTP>. (EOM)

fetchmail: SMTP< 250 ok 1229687061 qp 28123

 flushed

fetchmail: POP3> DELE 6

fetchmail: POP3< +OK 

fetchmail: POP3> QUIT

fetchmail: POP3< +OK 

fetchmail: SMTP> QUIT

So my mails comming from my ISP are just flushed.... grrrrr

Does any body encouterd this problem alreaddy ? My setup worked before I upgrade netqmail from 1.03 to 1.05.Last edited by democles on Sat Jan 03, 2009 7:33 pm; edited 2 times in total

----------

## democles

Hi there me again...

Did a lot of googling recently to find any solution. I think the problem is not related to fetchmail but might be netqmail related.

I read somewhere that netqmail-1.05 miscalculates the size of a mail (http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html)

3.4. RFC-1939 (POP3) violation (Mail size)

qmail-pop3d does not calculate mail sizes properly as documented in RFC-1939, section 11, but gives figures that are too low. 

 Indeed the size in my first post is to low....SIZE=6433 <6567

On [url] http://www.memoryhole.net/qmail/#size [/url] I found the following:

RFC 1870 (ESMTP SIZE)

    One useful extension people have made to the SMTP protocol is defined in RFC 1870, which establishes the SIZE command. This has two primary consequences. First, it announces (as a response to the initial EHLO greeting) the maximum size of mail that the server is willing to accept. Qmail's default behavior without this patch is to accept any amount of data and if the amount exceeds the maximum allowed, to reject it after it has been received. This wastes bandwidth: smart ESMTP senders that also support the SIZE command could have avoided wasting that bandwidth. Second, as part of the MAIL FROM command, the sender can specify the size of the mail it is going to send, allowing the receiver (qmail) to reject it at that point for being too big. 

There one can find a patch but can somebody can tell if those 2 are related? Might the proposed patch be the solution? 

Am I the only one having this problem?  :Embarassed:  Help would be much appreciated

----------

## honp

Hi, maybe you could try how your qmail react to small mails with qmail-inject?

H.

----------

## cach0rr0

 *Quote:*   

> 
> 
> 6567 actual != 6433 expected
> 
> 

 

What would you wager that extra 200 some-odd bytes is the "Received" header added

Which says to me the comparison of the MAIL command's SIZE argument to the size of 822 data is taking place in the wrong spot (i.e. *after* the Received header is added). Checks against ESMTP SIZE arg should take place prior to addition of Received header. 

just a guess, but that's well broken. That, or, your ISP is failing to account for its own Received header, and as such sending the wrong SIZE arg. 

Wouldn't know, I junked qmail in favour of postfix a good while back ;x

But yes, at least from the very short text on that page (which is a page I often cite to convince friends to ditch qmail!) it looks to be related.

also worth reading

http://www.disciplina.net/musings/qmail_rant

----------

## democles

Honp and cach0rr0,

Thanks for the reply. As for the qmail-inject.... too late because I wiped qmail out of my little homeserver (reading the links I posted above made me decide to use another package). Because I like vpopmail  a lot (and dovecot can use it)  I'm looking how I can combine it with softs like postfix or exim.

I will change the initial to solved even it actually isn't for many other users perhaps..

----------

## cach0rr0

cool deal, sorry i couldn't be of more help

if it's the least bit helpful...im very very slowly doc'ing my own setup - in my case, using postfix. 

all my .conf and whatnot. I don't use vpopmail or anything of the sort, and there's not much in the way of explaining why I've done what, but hopefully you can get some use of it. 

https://whitehathouston.com/topics/index.php/WHHMail

Eventually I'll put more on there, but I've had quite good results with my setup, using this as a basis

I too use dovecot with this, and the integration between the two has been completely painless

----------

## democles

Thanks for the helpfull link Cach0rr0 !

After I wiped out netqmail I began installing exim with the dovecot-sasl useflag. I'll have to do some more reading on working with exim (relative to virutal domains) but I'm progressing slowly. To my big suprise, when I tried fetchmail to get my mails from my ISP the same problem occured   :Crying or Very sad:  there was again a difference in size!! (less this time, about 43 Kb) I'll try getmail and see what it gives... and I'll question my ISP also.... to be continued

----------

## cach0rr0

Wonder if there's any way to prevent your ISP from utilizing the SIZE extension (i.e. simply don't advertise it in your response)

That doesn't fix the problem of course, but....unless you're in a fairly bandwidth-limited region, chances of you receiving an e-mail that's going to give you trouble as far as size goes is fairly slim. 

Plus, the ISP is quite likely already going to impose a fairly sane size limit on incoming e-mail.

----------

## democles

Hey there !... My little homeserver is back in business. I've been jumping to wrong conclusion too fast I think.

After a day of trial and errorI got it all working but this time with exim and dovecot. When we look back at my first post it isn't that problematic:  :Razz:  fetchmail indicates there is a problem with size but it doesn't stop the process. That the messages are flushed is normal because I don't want to keep them @ the popserver. ( I had told fetchmail not do that (default) i.e I did not use the 'keep' option)

As I mentionned before I've tried getmail (no probs) and I retried fetchmail with different options (keep...). After different tests and some finetuning of exim and spamassassin my mails are fetched and delivered to exim (yes with the size warning), CLAMAV and SA are handling the messages and are finally put in the maildir of my virtual users, ready to be served by dovecot.

I'll put my little howto exim dovecot online shortly !

Thanks to all posters for good advice/hints  :Cool: 

----------

