Attachment stripping - wrong postfix message size

Glenn Steen glenn.steen at gmail.com
Thu Mar 25 09:00:25 GMT 2010 

On 24 March 2010 10:59, Markus Nilsson <markus at markusoft.se> wrote:
> On 23 March 2010 17:07, Markus Nilsson <markus at markusoft.se> wrote:
>> Hi again,
>>
>> I've done a little bit of searching around in the source, enabled some debug prints etc, and can't find anywhere that the C-record metadata read from the original queuefile is edited. Am I missing something here, or is MailScanner ignoring any changes made to the mail in respect to size, and just lets the queue file keep its original C record?
>>
>> I would really need my postfix instance to give a correct estimation of the message size to the receiving mailserver when starting delivert since I am stripping away any large attachments, and the mails are quite smaller after being processed by MS!
>>
>>
>> /BR
>> Markus
>
> Hej Markus,
>
> Well... you might be right about the size thing, I haven't revisited
> that part in a while (and don't really have time to do so either,
> sorry).
> The thing that stikes me as somewhat odd though ... is why you would
> want to do anything like this...? I've alwasy kept my "max sizes" in
> sync, to the best of my ability. That way I never _need_ anything like
> that, since I've already rejected any message violating the message
> size limit.
>
> That being said, it'd be a Good Thing if Jules could be persuaded to
> take a look at the relevant code, or point you in the correct
> direction (ie where the update of the C record is "hidden":-).
>
> Cheers
> --
> -- Glenn
>
>
>
> Hej Glenn!,
>
> I want to do this because I don't reject the mail, I let it by with reduced
> size. I am then able to let the recipient download the attachment seperatley.
> In that way the message get through, and the attachment is retrievable, even
> if the recipient (a server out of my control) has rules that would reject large
> emails. But since it seems that my postfix instance believes that the email
> has the original size, it reports that size to the receiving mail server,
> which rejects it.
>
> I'm now into the Postfix.pm code, the sub PreDataString.
>
> I have successfully changed the C record to use $message->{size} as the message_size,
> but since the postfix queue file format is "intentionally undocumented" (sigh) it is
> hard to realize if I have ruined something else, I'm by no means sure what all fields mean...
>
> My code change, in Postfix.pm, PreDataString sub:
>
>    foreach (@{$message->{metadata}}) {
>      /^(.)(.*)$/;
>      ($type, $data) = ($1, $2);
>      $TimestampFound++ if $type eq 'T'; # Must only ever have 1 timestamp
>      #print STDERR "PreData1 Type $type Data $data\n";
> +      if($type eq 'C')
> +      {
> +        if ($data =~ m/(\D+)\d+(\D+\d+\D+\d+\D+\d+\D+)\d+/)
> +        {
> +          print STDERR "Size: " . $message->{size} . "\n";
> +          print STDERR "Data: (" . $data . ")\n";
> +          print STDERR "$1;$2;$3;$4\n";
> +          print STDERR "" . $data ."\n";
> +          $data = "" . $1 . $message->{size} . $2 . $message->{size};
> +          print STDERR "" . $data . "\n";
> +        }
> +        else
> +        {
> +          print STDERR "No match (" . $data . ") Leaving as is\n";
> +        }
>      }
>
> Please give me a hint if I should keep my hands off this code, or if this
> could be safe. I'm thinking of setting a flag in the message struct to
> tell if this change should be done or not, to only update the ones that
> really needs it.
>
Well, since this should be done as late as possible (just before
creating the new queue file), I sort of think you're at the right end.
Again, I haven't got the time to even check this code with/for you (am
in the middle of a big move ... work is relocating approximately 700
meters (Skeppsbron -> Regeringsgatan), but for all the work we need
do... it could be on the other side of the planet:-)... I presume you
have this running on a testbed, and that it isn't creating bad queue
files? The overhead for that code would be marginal, so ... the check
might actually cost you more that treating all alike:-).

I would probably have "solved" this by a more ... fascist... method...
simply mandating the message size limit to the customers.
But then, I don't run any ISP or message cleaning service:-).

Cheers
-- 
-- Glenn
>
> BR/
> Markus
>
>
>> ----- Original Message -----
>> From: "Markus Nilsson" <markus at markusoft.se>
>> To: mailscanner at lists.mailscanner.info
>> Sent: tisdag, 23 mar 2010 10:53:07
>> Subject: Attachment stripping - wrong postfix message size
>>
>> Hi,
>>
>> I'm having a problem with a custom function for attachment stripping based on total attachment size. The custom function is made for
>>
>> Maximum Attachment Size =
>>
>> I successfully return 1 if the summed size of all attachments are larger than my configured value, and -1 otherwise. The custom function also stores the attachments in a safe place for later retrieval. I then want MailScanner/postifx to deliver the stripped mail to the recipient(s). MailScanner seems to do it right, but for some reason when postfix delivers the mail to the receiving mail server, it reports the message size as it was before the stripping, so that server might reject the mail even though it really isn't that big.
>>
>> If I configure the mailserver to accept larger sizes, the received mail has the correct size (small, all attachments stripped), so the reported size by postfix is not correct!
>>
>> Does postfix somehow approximate the message size?
>> If so, is it possible to help postifix with this approximization?
>> Or am I completely missing something else out?
>>
>> Any help greatly appreciated!
>>
>> BR
>> Markus
>>
>>
>> --
>> MailScanner mailing list
>> mailscanner at lists.mailscanner.info
>> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>>
>> Before posting, read http://wiki.mailscanner.info/posting
>>
>> Support MailScanner development - buy the book off the website!
>>
>>
>>
>> --
>> MailScanner mailing list
>> mailscanner at lists.mailscanner.info
>> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>>
>> Before posting, read http://wiki.mailscanner.info/posting
>>
>> Support MailScanner development - buy the book off the website!
>>
>
>
>
> --
> -- Glenn
> email: glenn < dot > steen < at > gmail < dot > com
> work: glenn < dot > steen < at > ap1 < dot > se
> --
> MailScanner mailing list
> mailscanner at lists.mailscanner.info
> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>
> Before posting, read http://wiki.mailscanner.info/posting
>
> Support MailScanner development - buy the book off the website!
>
>
>
>
>
> --
> MailScanner mailing list
> mailscanner at lists.mailscanner.info
> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>
> Before posting, read http://wiki.mailscanner.info/posting
>
> Support MailScanner development - buy the book off the website!
>



-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se

More information about the MailScanner mailing list