[exim-dev] [Bug 938] New: 'smtp' transport does not assert '…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Brent Bloxam
Datum:  
To: exim-dev
Betreff: [exim-dev] [Bug 938] New: 'smtp' transport does not assert '\n' before sending '.' in DATA transmission
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=938
           Summary: 'smtp' transport does not assert '\n' before sending '.'
                    in DATA transmission
           Product: Exim
           Version: 4.69
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Transports
        AssignedTo: nigel@???
        ReportedBy: brentb@???
                CC: exim-dev@???



The 'smtp' transport does not assert that '\n' or '\r\n' has been sent before
sending '.' during a DATA transmission to an MTA. The result of this is that a
spooled message lacking '\n' at the end of its body will continuously timeout
and fail.

/var/log/exim/eximout.log:2009-12-21 08:00:00 1NLolk-0003aD-3V ==
email@??? >>> R=Storage T=Storage defer (-46): SMTP error from remote
mail server after end of >>> data: host 192.168.1.3 [192.168.1.3]: 421
mda.local SMTP incoming data timeout - >>> closing connection.

Somehow messages that match this condition are getting past our inbound queue
only Exim instance into our spool, and sit there until the retry rules
eventually give up and drop them. I have confirmed that adding '\n' to the end
of the spooled message body solves this issue.

I believe that appropriate functionality would be for exim to assert that a
message ends with '\n'. It might make more sense for this to happen during
initial spooling or routing, rather than within the transport (though I'm not
sure it will affect anything besides SMTP)


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email