Access To Fq Qmtp Daemon

[Kilby]

Having done a little reading on Mr. Bernstein's QMTP protocol (and thinking that this was probably the greatest thing since Governor Rockefeller outlawed pay toilets in New York State), I was pleased to see that FQ has the QMTP daemon up and running on Enigma.

Tried a little experiment using the simple script that comes with the manual pages for perl's Net::QMTP module.

Was able to connect both, directly and through an ssh tunnel to port 209 on Enigma and here are the results:

1. If a message is sent to a user at my domain the server seems to accept the message for delivery and the following confirmatory line is written "[user]@[tld]: success: ok 1066571005 qp 8609" (but, in fact, the message gets lost or eaten by the server and cannot be collected).

2. If a message is sent to an outside domain the server refuses to accept it and the following line is written "Dsorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)."

Can only surmise that the QMTP daemon is either broken or that FQ does not allow non-privileged users to access it successfully.

It would really be nice to be able to test performance under the QMTP daemon vs. the SMTP daemon.

Kilby

[Terra]

Can only surmise that the QMTP daemon is either broken or that FQ does not allow non-privileged users to access it successfully.

The QMTP daemon works extremely well, leading to the latter half of your statement being true... QMTP is the intra-server private communication (high speed low latency) framework amongst multiple mail servers... Think of it as a LAN instead of a WAN...

It would really be nice to be able to test performance under the QMTP daemon vs. the SMTP daemon.

That would be easily facilitated with your setting up Qmail + QMTP on your local development servers and peforming your testing there... Our mail engines are for production usage only, and are not made available for arbitrary testing... Testing in general will slowdown the primary queues as a side effect of being loaded up by test messages - which I'm sure will cause a line of site owners to start beating loudly on your door...

--
Terra
--it is fast enough--
FutureQuest

[Kilby]

"Testing in general will slowdown the primary queues as a side effect of being loaded up by test messages - which I'm sure will cause a line of site owners to start beating loudly on your door... "

Mr. Terra, I got your point. Beating loudly on my door I could probably take, but, beating on my head, now, that I would worry about :).

All kidding aside, does FQ have any plans to offer QMTP server access to its paying customers? I ask this because from the literature that I have read on the subject as well as your reply, QMTP appears to dance circles around SMTP in terms of simplicity and performance.

Kilby

[Terra]

I doubt it, at least in the short term, because SMTP reigns supreme...

QMTP is mostly an internal protocol for shuffling messages between internal mail servers... To use QMTP remotely, means that the mail server we are sending to must be listening QMTP as well... You won't find too terribly many of them...

I believe that if our outbound mail sender senses that the other side has QMTP, it will send that way, as this will be hinted upon by the 'distance' value within the MX record...

At this point, it is best to just inject your message and let our mail servers do the RightThing^TM...

--
Terra
--SMTP == T-Rex, QMTP == Velociraptor--
FutureQuest