0

Debian 7 setup, with Virtualmin/Webmin

Recently, I've had some complains by some people, who reported receiving the same emails, from a website hosted on my VPS, up to 300 times

A quick glance through the logs returns a lot of lines like the following:

postfix/error[12555]: 50C35800D: to=<******@tiscali.it>, relay=none, delay=173374, delays=173374/0.03/0/0.01, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with etb-4.mail.tiscali.it[213.205.33.61] while sending end of data -- message may be sent more than once)

Apparently this errors only applies to people with a @tiscali.it email, but I can't understand why, or how to stop it

Should I just disable the deferring? Would that cause other problems in the long run?


Update 1

Here's a more verbose log from mail.log

postfix/smtp[5392]: smtp_get: EOF
postfix/smtp[5392]: connect to subsystem private/defer
postfix/smtp[5392]: send attr nrequest = 0
postfix/smtp[5392]: send attr flags = 0
postfix/smtp[5392]: send attr queue_id = 8780426101
postfix/smtp[5392]: send attr original_recipient = *@tiscali.it
postfix/smtp[5392]: send attr recipient = *@tiscali.it
postfix/smtp[5392]: send attr offset = 604
postfix/smtp[5392]: send attr dsn_orig_rcpt = rfc822;*@tiscali.it
postfix/smtp[5392]: send attr notify_flags = 0
postfix/smtp[5392]: send attr status = 4.4.2
postfix/smtp[5392]: send attr diag_type =
postfix/smtp[5392]: send attr diag_text =
postfix/smtp[5392]: send attr mta_type =
postfix/smtp[5392]: send attr mta_mname =
postfix/smtp[5392]: send attr action = delayed
postfix/smtp[5392]: send attr reason = lost connection with etb-2.mail.tiscali.it[213.205.33.64] while sending end of data -- message may be sent more than once
postfix/smtp[5392]: private/defer socket: wanted attribute: status
postfix/smtp[5392]: input attribute name: status
postfix/smtp[5392]: input attribute value: 0
postfix/smtp[5392]: private/defer socket: wanted attribute: (list terminator)
postfix/smtp[5392]: input attribute name: (end)
postfix/smtp[5392]: 8780426101: to=<*@tiscali.it>, relay=etb-2.mail.tiscali.it[213.205.33.64]:25, delay=129, delays=0.05/0.02/78/50, dsn=4.4.2, status=deferred (lost connection with etb-2.mail.tiscali.it[213.205.33.64] while sending end of data -- message may be sent more than once)
  • what you can do is to record the smtp session to tiscali with tcpdump and the have a look at it in wireshark. ATTENTION: you may be breaching someone else's privacy if the mail contents are not your own. That said, what you are seeing could be the result of one side being too strict ("lost connection") and the other side too liberal with email reception - your MTA thinking that the mail transfer broke and the other side delivering it anyway. Analysing the wiredump might give you some hint. – Tomáš Pospíšek Dec 15 '17 at 17:32
  • Also, at least with exim there are plenty of command line options to debug mail sending "standalone". That is you can tell exim, look, take this message here and try to deliver it and please be very, very verbose about what's happening. I am sure postfix, being a very solid MTA, must have a similar array of debugging possibilities, not the least being increasing daemon log verbosity. – Tomáš Pospíšek Dec 15 '17 at 17:35
  • I've set up a more verbose logging, and registered a @tiscali.it mail myself, bug is still there, I'll add the log in the main question – Mdk Dec 15 '17 at 19:45
  • 1
    @TomášPospíšek The problem is obvious: Tiscali accepted the message for delivery, but then disconnected instead of returning 250. – Michael Hampton Dec 15 '17 at 21:49
  • 1
    Maybe, but then you risk losing mail when they decide not to accept one and hang up on you. The only proper solution is for Tiscali to fix their mail server. – Michael Hampton Dec 15 '17 at 21:55

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.