[exim-dev] [Bug 938] 'smtp' transport does not assert '\n' b…

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: J R Binks
Data:  
Para: exim-dev
Asunto: [exim-dev] [Bug 938] '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




--- Comment #5 from J R Binks <jethro.binks@???> 2009-12-22 10:55:46 ---
MailScanner works more or less the same with other MTAs I think. It watches
the incoming queue, grabs messages from it, does its work, then either puts
them in an outgoing queue which is processed by (another instance of) the MTA,
or directly launches the MTA to deliver them onwards (MailScanner itself
doesn't do SMTP).

It has an issue with postfix, recently discussed again, where (and I put here
my understanding of what I have read, I have no particular knowledge) postfix
chose to use the inode as the queue id, which can potentially cause a problem
when MS has finished with a message and wants to make it available for onward
delivery. Wietse is relatively hostile to MailScanner playing around in
postfix's queue like that, and as I recall disclaimed all responsibility for
any postfix installation using MailScanner. I suppose that's not unreasonable
from some point of view, but I think he rather took it to extremes and refuses
to make any useful compromises or entertain discussion - at least that was the
case some years ago. I don't know if the situation has thawed :)

No particular knowledge of sendmail, but as far as I know it's roughly the
same.

MailScanner did break when changes were made to Exim's queue file format; in
particular when acl variables and then named acl variables went in there. But
Julian and other developers were quick to take account of the changes and fix
MS.

Some proper API that provides opaque access to the queue without worrying about
the internal structure would be nice, but simple co-operation and exchange of
information has done well so far, this particular bug notwithstanding.

Yes Exim could take a holier-than-thou position on this -- thou shalt not
interfere with my queue -- but it would be more conducive to cordial relations
between two pieces of software that are often used together to be more
co-operative, especially given that Julian has had a bash at this one and not
managed to nail it so far.

The above is a point of view, and others may disagree as they wish.
Exim+MailScanner has worked extremely well for us over the years, and while we
try and move more and more of MailScanner's functionality into Exim to further
minimise backscatter and other issues, we want the relationship to continue to
work in the future.


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