Send gets stuck when the message has a binary attachment

[arturoc]

Adding a binary attachment makes the sent command get stuck and never finish until the server ends the connection. Sending a text attachment works fine. The binary attachment is only 98Kb.

[mdecimus]

In order to reproduce the problem, could you provide the code you're using and if possible also the binary attachment?

[mdecimus]

Closing as no reply was received in 14 days.

[jacg]

I've run into a problem that sounds similar to this one.

Here is some code which might help you reproduce it. I have replaced all the addresses, servers and credentials that I used in my test, with todo!()s.

The value of snip is crucial: with its current value (or greater) the message send hangs. For any smaller value of snip the message gets sent successfully without delay. Changing the length of the addresses used, changes the value of snip that crosses the threshold between success and failure, so it looks like it depends on total message size.

Every PDF I tried (whose size exceeds snip) caused this failure. Including ones I have managed to send successfully using the server I used in my tests (with manual MUAs).

use mail_send::{mail_builder::MessageBuilder, Transport};

#[tokio::main]
async fn main() {

    let snip = 55663;

    let sender_name = todo!();
    let sender_address = todo!();
    let smtp_server = todo!();
    let username = todo!();
    let pw = todo!();

    let recipient_name = todo!();
    let recipient_address = todo!();

    let pdf_attachment = include_bytes!("../../sample.pdf").as_ref();
    let pdf_attachment = &pdf_attachment[..snip];
    let message = format!("PDF attachment length: {}", pdf_attachment.len());
    println!("{message}");

    let message = MessageBuilder::new()
        .from((sender_name, sender_address))
        .to(vec![
            (recipient_name, recipient_address),
        ])
        .subject(&message)
        .text_body(&message)
        .binary_attachment("application/pdf", "attachment.pdf", pdf_attachment);

    Transport::new(smtp_server)
        .credentials(username, pw)
        .allow_invalid_certs(true)
        .connect_tls()
        .await
        .unwrap()
        .send(message)
        .await
        .unwrap();
}

[mdecimus]

Hi @jacg ,

I was able to reproduce the problem with your code snippet. The buffer was not being properly flushed, that is why it was getting stuck. I just pushed a fix for this bug to the main branch, can you confirm that it works for you as well?

Thanks.

[jacg]

I can confirm that it no longer blocks. But (after removing all the snipping) the PDF document arrives 'damaged' at the other end, and I cannot open it with any of the PDF viewers I tried.

[jacg]

The document I'm using to test is 95k, but the one that is received is 130k. I'll try to come up with some more precise information when I have more time. Would you like me to file a separate issue for this, or continue here?

[mdecimus]

It may be related to the same problem. I'm looking into this now and will send you an update soon.

[mdecimus]

Done, it should work now.

[jacg]

It seems to work correctly for me now.

Many thanks for the quick solution!

[mdecimus]

Great! Version 0.2.3 has been pushed to crates.io with the fix.