Re: newbie check Was [Re: port 25 submission settings sanity check]
On 08/30/2013 02:49 PM, John Levine wrote: submission 587/udp I've been doing this for a long time, and I've never seen anyone try to do SMTP over anything other than TCP. You'll see this for a lot of services in the file. The old practice was for IANA to assign both tcp and udp when a service requested either so seeing udp assigned to a service doesn't mean much if anything. Peter
RE: newbie check Was [Re: port 25 submission settings sanity check]
Well, As attachments get larger, and end users use email rather than ftp for file transfer for convenience sake, a UDP implementation, perhaps using UDP as a data streaming channel could become a very useful configuration, and the transfer speed over high latency links (think satellite etc) could improve immensely. T -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Peter Sent: Friday, 30 August 2013 12:15 PM To: postfix-users@postfix.org Subject: Re: newbie check Was [Re: port 25 submission settings sanity check] On 08/30/2013 08:53 AM, Terry Gilsenan wrote: There are no MTAs that accept submission on UDP, yet, so maybe reserved for future use? No, it's just the assignment from IANA. In the past when either a TCP or UDP port assignment was requested both were assigned, this does not mean that there is or ever was any intention to use the UDP port for the service: NOTE: URL removed for security purposes - contact terry.gilse...@interoil.com for support. Note that this is no longer the case (as per section 7.2 of the same RFC above). Peter ===[Disclaimer]=== This electronic transmission, including any attachments, is confidential, may contain privileged information and should be read or retained only by the intended recipient. If you received this message in error, please delete it from your system and notify the sender immediately. Any review, dissemination or other use of this information by persons or entities other than the intended recipient is strictly prohibited. ===[End]===
Re: newbie check Was [Re: port 25 submission settings sanity check]
As attachments get larger, and end users use email rather than ftp for file transfer for convenience sake, a UDP implementation, perhaps using UDP as a data streaming channel could become a very useful configuration, and the transfer speed over high latency links (think satellite etc) could improve immensely. Not necessarily. SMTP is not DNS or SNMP. A SMTP communication requires far more than two ip packets (question/answer). So, as some others already mentioned, for reliable submission the software has to ensure correct integrity and order of the submitted ip packets - even over unreliable and asynchronous media. To be in advantage over smtp/tcp those checks have to be faster than the highly optimised ones in your tcp stack. Jan
Re: newbie check Was [Re: port 25 submission settings sanity check]
On Aug 30, 2013, at 7:07 AM, Terry Gilsenan wrote: As attachments get larger, and end users use email rather than ftp for file transfer for convenience sake, a UDP implementation, perhaps using UDP as a data streaming channel could become a very useful configuration, and the transfer speed over high latency links (think satellite etc) could improve immensely. I don't think so. As Weitse said yesterday, to run SMTP successfully on UDP, he'd have to duplicate TCP's back-and-forth to make sure those bits got there, they were correct, in the right order, etc. If that were done, you'd be back at TCP overhead and speed (and reliability). Streaming movies is one thing; transfering legal documents and medical records is another. -- Glenn English Disclaimer: Any disclaimer attached to this message may be ignored. smime.p7s Description: S/MIME cryptographic signature
RE: newbie check Was [Re: port 25 submission settings sanity check]
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jan P. Kessler Sent: Saturday, 31 August 2013 12:21 AM To: postfix-users@postfix.org Subject: Re: newbie check Was [Re: port 25 submission settings sanity check] As attachments get larger, and end users use email rather than ftp for file transfer for convenience sake, a UDP implementation, perhaps using UDP as a data streaming channel could become a very useful configuration, and the transfer speed over high latency links (think satellite etc) could improve immensely. Not necessarily. SMTP is not DNS or SNMP. A SMTP communication requires far more than two ip packets (question/answer). So, as some others already mentioned, for reliable submission the software has to ensure correct integrity and order of the submitted ip packets - even over unreliable and asynchronous media. To be in advantage over smtp/tcp those checks have to be faster than the highly optimised ones in your tcp stack. Embedding sequence and CRC into the UDP packet as part of the data stream (at the application layer) will take care of the integrity and packet order, the lack of requirement for ACK will speed up the transfer over high latency links like satellite (typical RTT of 800-1300ms) Only packets that fail CRC or don’t arrive need retransmission. I have done testing with file transfers using both TCP and UDP, and the results are very surprising. I was thinking 10-15% improvement however, real world testing shows 50-70% improvement. There is no stop-wait-start with UDP, and if the data integrity is taken care of at the application layer then I suspect it will work fine. Implementing this as a data-channel that can negotiated during standard SMTP/Submission negotiation, maybe as an extension to ESMTP, eg: UPIPE, then that UDP connection us used to stream the MIME bulk. This could work, and if implemented well would be backward compatible too. T ===[Disclaimer]=== This electronic transmission, including any attachments, is confidential, may contain privileged information and should be read or retained only by the intended recipient. If you received this message in error, please delete it from your system and notify the sender immediately. Any review, dissemination or other use of this information by persons or entities other than the intended recipient is strictly prohibited. ===[End]===
RE: newbie check Was [Re: port 25 submission settings sanity check]
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Glenn English Sent: Saturday, 31 August 2013 12:52 AM To: postfix-users@postfix.org Subject: Re: newbie check Was [Re: port 25 submission settings sanity check] On Aug 30, 2013, at 7:07 AM, Terry Gilsenan wrote: As attachments get larger, and end users use email rather than ftp for file transfer for convenience sake, a UDP implementation, perhaps using UDP as a data streaming channel could become a very useful configuration, and the transfer speed over high latency links (think satellite etc) could improve immensely. I don't think so. As Weitse said yesterday, to run SMTP successfully on UDP, he'd have to duplicate TCP's back-and-forth to make sure those bits got there, they were correct, in the right order, etc. If that were done, you'd be back at TCP overhead and speed (and reliability). I am not talking about implementing SMTP on UDP, I am taking about the possibility of adding a side-channel for bulk data that would use UDP. If EC is handled within the application then it will work ok. UDP and TCP differ in that with TCP there is an overhead within the protocol that guarantees delivery. Data transfer over UDP can be just as reliable as TCP if the delivery guarantee mechanism is handled at the application layer. On reliable links with large RTT (latency) UDP with EC in the application is a whole world better than TCP. Try it some time with IPTables and netem, and setup a local router that will introduce a 1000ms delay into your network, then try using a vpn like say, OpenVPN in UDP mode (UDP 1194) and then in TCP (TCP 443) mode and you will soon see what I am talking about. The UDP connection will far outshine the TCP connection where RTT is 400ms+ Use netem to drop the RTT down to 200ms and the advantage reduces, drop the RTT to 30ms and the improvement reduces again. On satellite links (they are millions of these) the latency significantly impacts the size of the TCP window, and drastically impacts the maximum available bandwidth. This effect is almost completely moot when UDP is used. T ===[Disclaimer]=== This electronic transmission, including any attachments, is confidential, may contain privileged information and should be read or retained only by the intended recipient. If you received this message in error, please delete it from your system and notify the sender immediately. Any review, dissemination or other use of this information by persons or entities other than the intended recipient is strictly prohibited. ===[End]===
RE: newbie check Was [Re: port 25 submission settings sanity check]
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Glenn English Sent: Saturday, 31 August 2013 12:52 AM To: postfix-users@postfix.org Subject: Re: newbie check Was [Re: port 25 submission settings sanity check] On Aug 30, 2013, at 7:07 AM, Terry Gilsenan wrote: As attachments get larger, and end users use email rather than ftp for file transfer for convenience sake, a UDP implementation, perhaps using UDP as a data streaming channel could become a very useful configuration, and the transfer speed over high latency links (think satellite etc) could improve immensely. I don't think so. As Weitse said yesterday, to run SMTP successfully on UDP, he'd have to duplicate TCP's back-and-forth to make sure those bits got there, they were correct, in the right order, etc. If that were done, you'd be back at TCP overhead and speed (and reliability). Streaming movies is one thing; transfering legal documents and medical records is another. There are many file transfer systems that use UDP and take care of integrity within the application layer. Many online backup services use UDP, and they do that for reasons of speed. If they couldn't guarantee data integrity then they would be worse than useless. If each UDP segment was prepended with a CRC and sequence number before being sent, then the application at the other end can take care of packet order, and requesting resend of a packet where there is a gap in the sequence numbers. Not trivial perhaps, but certainly not hard. Many applications already do this. ===[Disclaimer]=== This electronic transmission, including any attachments, is confidential, may contain privileged information and should be read or retained only by the intended recipient. If you received this message in error, please delete it from your system and notify the sender immediately. Any review, dissemination or other use of this information by persons or entities other than the intended recipient is strictly prohibited. ===[End]===
Re: newbie check Was [Re: port 25 submission settings sanity check]
On 8/30/2013 10:12 AM, Terry Gilsenan wrote: I am not talking about implementing SMTP on UDP, I am taking about the possibility of adding a side-channel for bulk data that would use UDP. I'm really surprised nobody has mentioned this yet. It seems there's a far simpler solution to the described high latency low bandwidth attachment transfer problem: TCP send/receive buffer size. If all receiving systems advertised a sufficiently large receive buffer and clients could match it, then this latency/bandwidth problem pretty much evaporates. A 1MB buffer allows a 50MB attachment to be sent requiring only 50 ACKs. Assuming the path is fairly reliable, which has been your assumption in your UDP argument, then this is a far less invasive solution with similar performance. IIRC, not may years ago, a team comprised of personnel at Argonne and CERN achieved sustained saturation of a 1 Gbps link between Chicago and Geneva, using parallel FTP and an insanely large TCP buffer, like in the multiple GB range. I'll have to dig it up. This demonstrates that high bandwidth TCP over high latency links is achievable. -- Stan
newbie check Was [Re: port 25 submission settings sanity check]
On Aug 29, 2013, at 12:49 PM, Quanah Gibson-Mount wrote: --On Thursday, August 29, 2013 3:59 PM +0900 peter evans pe...@ixp.jp wrote: Combine these two into one. put permit_sasl_ at the top as it is a first match wins thing. And of course, re-educate your client that auth belongs on port 587. (for example, Japan has a lot of places outright blocking port 25.[1]) Yes, so does the US. I have already requested the customer be educated about proper ports to use, but they are quite insistent on using 25 for whatever reasons. I'm under the impression that 587 is to be used by my local users (email clients to local MTA), and 25 is used by MTA-MTA. Is this wrong? And /etc/services says: auth 113/tcp authentication tap ident not 587... -- Glenn English smime.p7s Description: S/MIME cryptographic signature
Re: newbie check Was [Re: port 25 submission settings sanity check]
Am 29.08.2013 21:34, schrieb Glenn English: I'm under the impression that 587 is to be used by my local users (email clients to local MTA), and 25 is used by MTA-MTA. Is this wrong? correct And /etc/services says: auth 113/tcp authentication tap ident not 587... grep for the port and not for auth :-) submission 587/tcp msa # mail message submission
Re: newbie check Was [Re: port 25 submission settings sanity check]
On Aug 29, 2013, at 1:37 PM, li...@rhsoft.net wrote: Am 29.08.2013 21:34, schrieb Glenn English: I'm under the impression that 587 is to be used by my local users (email clients to local MTA), and 25 is used by MTA-MTA. Is this wrong? correct And /etc/services says: auth113/tcp authentication tap ident not 587... grep for the port and not for auth :-) submission 587/tcp msa # mail message submission Thank you. -- Glenn English smime.p7s Description: S/MIME cryptographic signature
Re: newbie check Was [Re: port 25 submission settings sanity check]
On 29 Aug 2013, at 13:34 , Glenn English g...@slsware.com wrote: On Aug 29, 2013, at 12:49 PM, Quanah Gibson-Mount wrote: --On Thursday, August 29, 2013 3:59 PM +0900 peter evans pe...@ixp.jp wrote: Combine these two into one. put permit_sasl_ at the top as it is a first match wins thing. And of course, re-educate your client that auth belongs on port 587. (for example, Japan has a lot of places outright blocking port 25.[1]) Yes, so does the US. I have already requested the customer be educated about proper ports to use, but they are quite insistent on using 25 for whatever reasons. I'm under the impression that 587 is to be used by my local users It is to be used by any users who are authorized to send and received mail on your server. 25 *should* only be used for MTAs to send mail to a user on your mailserver. (email clients to local MTA), and 25 is used by MTA-MTA. Is this wrong? And /etc/services says: auth 113/tcp authentication tap ident ident has nothing to do with mail. ident has nothing to do with anything anymore, really. I think the only people that still use ident are some IRC servers, and most users have to fake an ident server in their IRC client. $ grep 587 /etc/services submission 587/tcp submission 587/udp -- 'Where do shadows come from? That's where the wind is blowing!' --Colour of Magic
Re: newbie check Was [Re: port 25 submission settings sanity check]
On Aug 29, 2013, at 2:18 PM, LuKreme wrote: $ grep 587 /etc/services submission 587/tcp submission 587/udp That's what mine says too. Does Postfix accept UDP submissions? I looked at RFC6409 (the newest I could find on 587), and all it said was port 587 -- the protocol isn't mentioned. -- Glenn English smime.p7s Description: S/MIME cryptographic signature
RE: newbie check Was [Re: port 25 submission settings sanity check]
There are no MTAs that accept submission on UDP, yet, so maybe reserved for future use? t From: Glenn Englishmailto:g...@slsware.com Sent: 29/08/2013 3:44 PM To: postfix-users@postfix.orgmailto:postfix-users@postfix.org Subject: Re: newbie check Was [Re: port 25 submission settings sanity check] On Aug 29, 2013, at 2:18 PM, LuKreme wrote: $ grep 587 /etc/services submission 587/tcp submission 587/udp That's what mine says too. Does Postfix accept UDP submissions? I looked at RFC6409 (the newest I could find on 587), and all it said was port 587 -- the protocol isn't mentioned. -- Glenn English ===[Disclaimer]=== This electronic transmission, including any attachments, is confidential, may contain privileged information and should be read or retained only by the intended recipient. If you received this message in error, please delete it from your system and notify the sender immediately. Any review, dissemination or other use of this information by persons or entities other than the intended recipient is strictly prohibited. ===[End]===
Re: newbie check Was [Re: port 25 submission settings sanity check]
On 8/29/2013 3:43 PM, Glenn English wrote: On Aug 29, 2013, at 2:18 PM, LuKreme wrote: $ grep 587 /etc/services submission 587/tcp submission 587/udp That's what mine says too. Does Postfix accept UDP submissions? I looked at RFC6409 (the newest I could find on 587), and all it said was port 587 -- the protocol isn't mentioned. It's standard SMTP over tcp, typically with STARTTLS and AUTH. I imagine the udp entry is a historical artifact. -- Noel Jones
Re: newbie check Was [Re: port 25 submission settings sanity check]
On 08/30/2013 08:53 AM, Terry Gilsenan wrote: There are no MTAs that accept submission on UDP, yet, so maybe reserved for future use? No, it's just the assignment from IANA. In the past when either a TCP or UDP port assignment was requested both were assigned, this does not mean that there is or ever was any intention to use the UDP port for the service: http://tools.ietf.org/html/rfc6335#section-7.1 Note that this is no longer the case (as per section 7.2 of the same RFC above). Peter
Re: newbie check Was [Re: port 25 submission settings sanity check]
submission 587/udp I've been doing this for a long time, and I've never seen anyone try to do SMTP over anything other than TCP. Regards, John Levine, postmas...@cauce.org, CAUCE postmaster http://www.cauce.org
