Re: Postfix talking smtp through stdio command?

2011-09-10 Thread Matthias Andree
Am 07.09.2011 19:05, schrieb Jeroen Geilman:
 On 2011-09-07 00:55, Matthias Andree wrote:
 The firewall block is deliberate.
 
 Then I suggest you talk to some people and tell them you need email
 access...
 I find it rather quaint that you would be trying to set up SMTP
 connectivity on a system where this has - as you say - been expressly
 forbidden.

These people allow me to use SSH tunnels, but their Postfix doesn't talk
AUTH.  If someone is aware of an SASL implementation for Postfix that
authenticates users through SSH public keys in their
~SOMEUSER/.ssh/authorized_keys files, I'm all ears. :)


Re: Postfix talking smtp through stdio command?

2011-09-10 Thread Matthias Andree
Am 07.09.2011 19:13, schrieb Bastian Blank:
 On Tue, Sep 06, 2011 at 08:59:20PM +0200, Matthias Andree wrote:
 Can you describe the problem instead of the solution? There may be
 other solutions than the ones you have in mind.
 The problem is this:
 - I *can* (and am permitted to) connect to a computer in the same LAN as
 the SMTP server by SSH.
 
 One quiet old solution is UUCP-over-ssh. It is reliable, batches mail in
 both direction and does not need much ressources.

There's an idea, and might actually work given the destination
environment.  I know that I can make Postfix talk to uux, I don't
remember having used uucico over ssh, but I'll see if that's feasible.
(The other side runs on FreeBSD, so I think a Unixish solution is
appealing enough to have the admins consider it. :))


Re: Postfix talking smtp through stdio command?

2011-09-10 Thread Matthias Andree
Am 06.09.2011 19:30, schrieb Ansgar Wiechers:
 On 2011-09-06 Matthias Andree wrote:
 I am in a situation where I would like to achieve either of these
 solutions:

 Alternative A:

 - have Postfix's smtp client talk through a command via stdin/stdout
 (instead of a TCP stream).

 That command would be ssh -W mailhub:25, with a user-specified
 password and possibly some sort of credentials cache (like ssh-agent).

 - Ideally, I would be able to pass relevant environment variables such
 as SSH_AUTH_SOCK to the SMTP client somehow, and Postfix's smtp client
 would run under my own unprivileged user ID if possible (else I need
 to find a proxy for ssh-agent, too, because it checks the peer user
 ID).

 - What I can do, but dislike because it's unreliable and consequently
 insecure, is: set up a regular ssh tunnel (with local listening TCP
 stream socket) with -L local forwarding and redirect Postfix there.
 
 What makes you believe that an SSH tunnel were any less reliable than
 ssh -W?

The tight coupling (on client side) through stdio is what matters here.
 If I put localhost:1234 as my relayhost and someone else grabs that
port, my mail is possibly gone if it's a different SMTP server rather
than the hoped-for SSH tunnel.  Not acceptable.


Re: Postfix talking smtp through stdio command?

2011-09-10 Thread Reindl Harald


Am 10.09.2011 17:06, schrieb Matthias Andree:
 Am 06.09.2011 19:30, schrieb Ansgar Wiechers:
 On 2011-09-06 Matthias Andree wrote:
 I am in a situation where I would like to achieve either of these
 solutions:

 Alternative A:

 - have Postfix's smtp client talk through a command via stdin/stdout
 (instead of a TCP stream).

 That command would be ssh -W mailhub:25, with a user-specified
 password and possibly some sort of credentials cache (like ssh-agent).

 - Ideally, I would be able to pass relevant environment variables such
 as SSH_AUTH_SOCK to the SMTP client somehow, and Postfix's smtp client
 would run under my own unprivileged user ID if possible (else I need
 to find a proxy for ssh-agent, too, because it checks the peer user
 ID).

 - What I can do, but dislike because it's unreliable and consequently
 insecure, is: set up a regular ssh tunnel (with local listening TCP
 stream socket) with -L local forwarding and redirect Postfix there.

 What makes you believe that an SSH tunnel were any less reliable than
 ssh -W?
 
 The tight coupling (on client side) through stdio is what matters here.
 If I put localhost:1234 as my relayhost and someone else grabs that
 port, my mail is possibly gone if it's a different SMTP server rather
 than the hoped-for SSH tunnel. Not acceptable

if someone else can grab the port you have really bigger problems as that

but anyways, you can start the tunnel as root and take a port  1024
so only root-users can grab the port and if you have not enough trust
to root-users really really leave this company :-)






signature.asc
Description: OpenPGP digital signature


Re: Postfix talking smtp through stdio command?

2011-09-07 Thread Jeroen Geilman

On 2011-09-07 00:55, Matthias Andree wrote:

The firewall block is deliberate.


Then I suggest you talk to some people and tell them you need email 
access...
I find it rather quaint that you would be trying to set up SMTP 
connectivity on a system where this has - as you say - been expressly 
forbidden.


--
J.



Re: Postfix talking smtp through stdio command?

2011-09-07 Thread Bastian Blank
On Tue, Sep 06, 2011 at 08:59:20PM +0200, Matthias Andree wrote:
  Can you describe the problem instead of the solution? There may be
  other solutions than the ones you have in mind.
 The problem is this:
 - I *can* (and am permitted to) connect to a computer in the same LAN as
 the SMTP server by SSH.

One quiet old solution is UUCP-over-ssh. It is reliable, batches mail in
both direction and does not need much ressources.

Bastian

-- 
Killing is wrong.
-- Losira, That Which Survives, stardate unknown


Re: Postfix talking smtp through stdio command?

2011-09-06 Thread Wietse Venema
Matthias Andree:
 Greetings,
 
 I am in a situation where I would like to achieve either of these solutions:
 
 Alternative A:
 
 - have Postfix's smtp client talk through a command via stdin/stdout
 (instead of a TCP stream).

Can you describe the problem instead of the solution? There may be
other solutions than the ones you have in mind.

Wietse


Re: Postfix talking smtp through stdio command?

2011-09-06 Thread Ansgar Wiechers
On 2011-09-06 Matthias Andree wrote:
 I am in a situation where I would like to achieve either of these
 solutions:
 
 Alternative A:
 
 - have Postfix's smtp client talk through a command via stdin/stdout
 (instead of a TCP stream).
 
 That command would be ssh -W mailhub:25, with a user-specified
 password and possibly some sort of credentials cache (like ssh-agent).
 
 - Ideally, I would be able to pass relevant environment variables such
 as SSH_AUTH_SOCK to the SMTP client somehow, and Postfix's smtp client
 would run under my own unprivileged user ID if possible (else I need
 to find a proxy for ssh-agent, too, because it checks the peer user
 ID).
 
 - What I can do, but dislike because it's unreliable and consequently
 insecure, is: set up a regular ssh tunnel (with local listening TCP
 stream socket) with -L local forwarding and redirect Postfix there.

What makes you believe that an SSH tunnel were any less reliable than
ssh -W?

Regards
Ansgar Wiechers
-- 
All vulnerabilities deserve a public fear period prior to patches
becoming available.
--Jason Coombs on Bugtraq


Re: Postfix talking smtp through stdio command?

2011-09-06 Thread Matthias Andree
Am 06.09.2011 19:30, schrieb Wietse Venema:
 Matthias Andree:
 Greetings,

 I am in a situation where I would like to achieve either of these solutions:

 Alternative A:

 - have Postfix's smtp client talk through a command via stdin/stdout
 (instead of a TCP stream).
 
 Can you describe the problem instead of the solution? There may be
 other solutions than the ones you have in mind.

The problem is this:

- I cannot connect to the remote SMTP relayhost via plain TCP, it's
firewalled on all ports.

- The relayhost does not offer submission STARTTLS or SSL-wrapped legacy
ports.

- I *can* (and am permitted to) connect to a computer in the same LAN as
the SMTP server by SSH.

- The authentication infrastructure only supports SSH-2 public/private
key authentication.


The current solution is (options are: -f = background, -M = master, so
as to keep the command alive, -N = no command, -L = port forward)

ssh -f -M -N -L :mailhub.example.org:25 sshgate.example.org

This particular tunnel I'd like to get rid of.  1) It gets stuck across
a computer's suspend (I suspect that's a misconfiguration of the
firewall and it should die some 2:19 hours after an attempt to send mail
because the Linux kernel I'm using would finally consider the TCP stream
dead); 2) if for some reason it's not my own SSH process listening on
port , I'm in trouble.


Arguably this should be fixed with authenticated submission (port 587),
possibly with certificates; but it has not happened in a year although
people promised to look into it.


Re: Postfix talking smtp through stdio command?

2011-09-06 Thread Wietse Venema
Matthias Andree:
[ Charset ISO-8859-1 unsupported, converting... ]
 Am 06.09.2011 19:30, schrieb Wietse Venema:
  Matthias Andree:
  Greetings,
 
  I am in a situation where I would like to achieve either of these 
  solutions:
 
  Alternative A:
 
  - have Postfix's smtp client talk through a command via stdin/stdout
  (instead of a TCP stream).
  
  Can you describe the problem instead of the solution? There may be
  other solutions than the ones you have in mind.
 
 The problem is this:
 
 - I cannot connect to the remote SMTP relayhost via plain TCP, it's
 firewalled on all ports.
 
 - The relayhost does not offer submission STARTTLS or SSL-wrapped legacy
 ports.
 
 - I *can* (and am permitted to) connect to a computer in the same LAN as
 the SMTP server by SSH.
 
 - The authentication infrastructure only supports SSH-2 public/private
 key authentication.

You did not mention this, but does your machine have a static IP
address? Then (a cron job on) the machine in the remote LAN could
call out to your machine over TCP, or SSL over TCP, through an
appropriate hole poked in the local firewall. Sounds like a fun
Perl programming project.

Wietse


Re: Postfix talking smtp through stdio command?

2011-09-06 Thread Peter Blair
On Tue, Sep 6, 2011 at 2:59 PM, Matthias Andree matthias.and...@gmx.de wrote:
 The problem is this:

 - I cannot connect to the remote SMTP relayhost via plain TCP, it's
 firewalled on all ports.

 - The relayhost does not offer submission STARTTLS or SSL-wrapped legacy
 ports.

 - I *can* (and am permitted to) connect to a computer in the same LAN as
 the SMTP server by SSH.

 - The authentication infrastructure only supports SSH-2 public/private
 key authentication.


 The current solution is (options are: -f = background, -M = master, so
 as to keep the command alive, -N = no command, -L = port forward)

 ssh -f -M -N -L :mailhub.example.org:25 sshgate.example.org

After a couple of minutes of playing around, I can:

pblair@pblair-laptop:~$ cat test-message.txt | ssh popc...@example.com
~/bin/smtp-cli --host=mail.EXAMPLE.COM --auth --user=popcorn
--pass=  --to=recipi...@example.com --from=sen...@example.com
--data=-

Using http://www.logix.cz/michal/devel/smtp-cli/ as the SMTP CLI client.

You could hack up a local perl SMTP listener on you local system,
which when it receives all of the SMTP back and forth, and then the
., it executes a SSH subshell, formatting the recipient/sender etc
via the gateway, and pipes the DATA portion over its FH.

Good luck!


Re: Postfix talking smtp through stdio command?

2011-09-06 Thread Matthias Andree
Am 06.09.2011 22:04, schrieb Peter Blair:

 You could hack up a local perl SMTP listener on you local system,
 which when it receives all of the SMTP back and forth, and then the
 ., it executes a SSH subshell, formatting the recipient/sender etc
 via the gateway, and pipes the DATA portion over its FH.

This local listener is what I already have (it's not ssh that's
unreliable, but the overall design that's fragile), and it is exactly
what I'm trying to avoid.

I want a tighter, synchronous, coupling between the local SMTP client
and the remote SMTP server.  Nothing that relies on the ssh tunnel being
up in the exact moment when Postfix/smtp chooses it wants to relay a
message because that I cannot guarantee.


Re: Postfix talking smtp through stdio command?

2011-09-06 Thread /dev/rob0
On Tuesday 06 September 2011 13:59:20 Matthias Andree wrote:
 Am 06.09.2011 19:30, schrieb Wietse Venema:
  Matthias Andree:
  Greetings,
  
  I am in a situation where I would like to achieve either of
  these solutions:
  
  Alternative A:
  
  - have Postfix's smtp client talk through a command via
  stdin/stdout (instead of a TCP stream).
  
  Can you describe the problem instead of the solution? There may
  be other solutions than the ones you have in mind.
 
 The problem is this:
 
 - I cannot connect to the remote SMTP relayhost via plain TCP, it's
 firewalled on all ports.
 
 - The relayhost does not offer submission STARTTLS or SSL-wrapped
 legacy ports.
 
 - I *can* (and am permitted to) connect to a computer in the same
 LAN as the SMTP server by SSH.

If you have root on this internal machine, or if you can persuade the 
administrator to allow it, you can set up a p2p-mode openvpn between 
your host and the one you SSH to. This can punch through closed 
firewalls, because each endpoint is trying to send packets to the same 
UDP port on the other. A stateful firewall will typically assume that 
the outside host is replying to the LAN host.

If either endpoint is on a dynamic IP address, you need some means of 
notifying the other one what IP to send packets to. Dynamic DNS 
(nsupdate) is one way, something scripted with ssh is another way.

Once your VPN is in place, simply use the VPN IP address as your 
relayhost. Use NAT if necessary to get to the remote SMTP host, or 
just set up routing such that reply packets are routed through the 
tunnel.

This mail is being relayed through an openvpn tunnel, FWIW.

 - The authentication infrastructure only supports SSH-2
 public/private key authentication.
 
 
 The current solution is (options are: -f = background, -M = master,
 so as to keep the command alive, -N = no command, -L = port
 forward)
 
 ssh -f -M -N -L :mailhub.example.org:25 sshgate.example.org
 
 This particular tunnel I'd like to get rid of.  1) It gets stuck
 across a computer's suspend (I suspect that's a misconfiguration
 of the firewall and it should die some 2:19 hours after an attempt
 to send mail because the Linux kernel I'm using would finally
 consider the TCP stream dead); 2) if for some reason it's not my
 own SSH process listening on port , I'm in trouble.
 
 
 Arguably this should be fixed with authenticated submission (port
 587), possibly with certificates; but it has not happened in a
 year although people promised to look into it.

-- 
Offlist mail to this address is discarded unless
/dev/rob0 or not-spam is in Subject: header


Re: Postfix talking smtp through stdio command?

2011-09-06 Thread Matthias Andree
Am 06.09.2011 22:41, schrieb /dev/rob0:
 On Tuesday 06 September 2011 13:59:20 Matthias Andree wrote:
 Am 06.09.2011 19:30, schrieb Wietse Venema:
 Matthias Andree:
 Greetings,

 I am in a situation where I would like to achieve either of
 these solutions:

 Alternative A:

 - have Postfix's smtp client talk through a command via
 stdin/stdout (instead of a TCP stream).

 Can you describe the problem instead of the solution? There may
 be other solutions than the ones you have in mind.

 The problem is this:

 - I cannot connect to the remote SMTP relayhost via plain TCP, it's
 firewalled on all ports.

 - The relayhost does not offer submission STARTTLS or SSL-wrapped
 legacy ports.

 - I *can* (and am permitted to) connect to a computer in the same
 LAN as the SMTP server by SSH.
 
 If you have root on this internal machine, or if you can persuade the 
 administrator to allow it, you can set up a p2p-mode openvpn between 
 your host and the one you SSH to. This can punch through closed 
 firewalls, because each endpoint is trying to send packets to the same 
 UDP port on the other. A stateful firewall will typically assume that 
 the outside host is replying to the LAN host.

Good plan, but neither root nor any chance to persuade $admin.

The firewall block is deliberate.  I've set up OpenVPN more than once,
so that would've been easy. 8-)