- ... 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? ... not 587...Message 1 of 34 , Aug 29, 2013View SourceOn Aug 29, 2013, at 12:49 PM, Quanah Gibson-Mount wrote:
> --On Thursday, August 29, 2013 3:59 PM +0900 peter evans <peter@...> wrote: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?
>> 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.)
> 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.
And /etc/services says:
> auth 113/tcp authentication tap identnot 587...
- ... I m really surprised nobody has mentioned this yet. It seems there s a far simpler solution to the described high latency low bandwidth attachmentMessage 34 of 34 , Aug 30, 2013View SourceOn 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