I'm sure I should be able to solve this one easily with help from Google but I've drawn a blank so far.
I have a basic box installed with Ubuntu-server (8.04), pretty much a default install. I want to send a couple of files from that box as attachments by email.
I'm looking for the minimum necessary to do this. I don't really see the need for a mail server (it just needs to do a DNS lookup for an MX record then SMTP direct to that). I have so far installed mutt but that's unable to send without something extra being installed.
2008/10/9 Mark Rogers mark@quarella.co.uk
I have a basic box installed with Ubuntu-server (8.04), pretty much a default install. I want to send a couple of files from that box as attachments by email.
I'm looking for the minimum necessary to do this. I don't really see the need for a mail server (it just needs to do a DNS lookup for an MX record then SMTP direct to that). I have so far installed mutt but that's unable to send without something extra being installed.
Try installing nullmailer. That queues and forwards mail to a specified external smarthost. JD
On Thu, Oct 09, 2008 at 05:12:53PM +0100, Mark Rogers wrote:
I'm sure I should be able to solve this one easily with help from Google but I've drawn a blank so far.
I have a basic box installed with Ubuntu-server (8.04), pretty much a default install. I want to send a couple of files from that box as attachments by email.
I'm looking for the minimum necessary to do this. I don't really see the need for a mail server (it just needs to do a DNS lookup for an MX record then SMTP direct to that). I have so far installed mutt but that's unable to send without something extra being installed.
Mutt *does* have minimal SMTP capability now, since about version 1.5.15 I think it is. On Ubuntu 8.10 (beta) I get version 1.5.18 of mutt so that can do SMTP itself.
See what version of mutt you have got and, if it's new enough, then you probably need some configuration magic to get it going (though it *might* not be compiled in I suppose).
If your mutt really doesn't have SMTP then you have two alternatives (using mutt anyway):-
Compile your own mutt, a version that does SMTP
Get one of the minimal MTAs, there are several, if you take a look at the mutt web site (www.mutt.org) there are two or three recommended.
Personally I'd go for a mutt with SMTP built in, I found the 'simple' MTAs for mutt weren't usually very simple.
Chris G wrote:
Mutt *does* have minimal SMTP capability now, since about version 1.5.15 I think it is. On Ubuntu 8.10 (beta) I get version 1.5.18 of mutt so that can do SMTP itself.
On 8.04 it's 1.5.17 so I like this idea.
Any idea how I'd find out whether it has this capability or how to configure it?
On Thu, Oct 09, 2008 at 06:21:45PM +0100, Mark Rogers wrote:
Chris G wrote:
Mutt *does* have minimal SMTP capability now, since about version 1.5.15 I think it is. On Ubuntu 8.10 (beta) I get version 1.5.18 of mutt so that can do SMTP itself.
On 8.04 it's 1.5.17 so I like this idea.
Any idea how I'd find out whether it has this capability or how to configure it?
Run "mutt -v | grep SMTP" from the command line, if you get a line with "+USE_SMTP" in it then you have built-in SMTP capability. I think you almost certainly have because the version in 8.10 has the capability.
For instructions on how to set it up go to the mutt web site:-
http://www.mutt.org/doc/devel/manual.html#smtp
It's fairly straightforward (but I'm a long time mutt user so maybe I have rose tinted spectacles). Any problems ask some more.
Chris G wrote:
Run "mutt -v | grep SMTP" from the command line, if you get a line with "+USE_SMTP" in it then you have built-in SMTP capability.
I do!
For instructions on how to set it up go to the mutt web site:-
http://www.mutt.org/doc/devel/manual.html#smtp
OK, I've read those docs and I'm not sure I'm going to get 100% to where I want to be, but I can probably fiddle what I need.
Ideally I'd like NOT to go via a smarthost, just have mutt (or whatever) lookup the MX record and go direct. Is there a way to do that?
But I reckon I can set it up to go via a smarthost for now.
On Fri, Oct 10, 2008 at 01:12:29PM +0100, Mark Rogers wrote:
Chris G wrote:
Run "mutt -v | grep SMTP" from the command line, if you get a line with "+USE_SMTP" in it then you have built-in SMTP capability.
I do!
For instructions on how to set it up go to the mutt web site:-
http://www.mutt.org/doc/devel/manual.html#smtpOK, I've read those docs and I'm not sure I'm going to get 100% to where I want to be, but I can probably fiddle what I need.
Ideally I'd like NOT to go via a smarthost, just have mutt (or whatever) lookup the MX record and go direct. Is there a way to do that?
I suspect not but I'm not absolutely sure, you could ask on the mutt mailing list or in the mutt newsgroup.
But I reckon I can set it up to go via a smarthost for now.
On 10 Oct 13:12, Mark Rogers wrote:
Chris G wrote:
Run "mutt -v | grep SMTP" from the command line, if you get a line with "+USE_SMTP" in it then you have built-in SMTP capability.
I do!
For instructions on how to set it up go to the mutt web site:-
http://www.mutt.org/doc/devel/manual.html#smtpOK, I've read those docs and I'm not sure I'm going to get 100% to where I want to be, but I can probably fiddle what I need.
Ideally I'd like NOT to go via a smarthost, just have mutt (or whatever) lookup the MX record and go direct. Is there a way to do that?
BINGBINGBINGBING...
1) Has the server got a fixed IP? 2) Has the server got a *valid* PTR record
Without those, you're fighting a losing battle talking directly to the MX servers anyways.
On top of that, with the adoption of greylisting, and with sender callouts, you need to make sure that the MX for the domain you're sending from is available, you need to be able to queue mail, and that the MX for the domain you're sending from will let people do callbacks.
If none of that makes sense - use a smart host. Seriously.
Cheers,
Brett Parker wrote:
BINGBINGBINGBING...
Time to get lunch out of the microwave....
- Has the server got a fixed IP?
- Has the server got a *valid* PTR record
Without those, you're fighting a losing battle talking directly to the MX servers anyways.
Yeah, I know, but this is specifically for me logging into a box via SSH and sending a file "home", ie to me, so I have some control over the checks which take place on the incoming mail.
On top of that, with the adoption of greylisting, and with sender callouts, you need to make sure that the MX for the domain you're sending from is available, you need to be able to queue mail, and that the MX for the domain you're sending from will let people do callbacks.
If none of that makes sense - use a smart host. Seriously.
It does make sense, and the smart host comment is agreed with in general.
On Fri, 10 Oct 2008 14:24:29 +0100 Mark Rogers mark@quarella.co.uk allegedly wrote:
Yeah, I know, but this is specifically for me logging into a box via SSH and sending a file "home", ie to me, so I have some control over the checks which take place on the incoming mail.
Forgive me, I'm curious.
If you have ssh access to this machine and just want to send a couple of files back home, why do you want to use SMTP as the file transport mechanism?
Mick ---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
mbm wrote:
On Fri, 10 Oct 2008 14:24:29 +0100 Mark Rogers mark@quarella.co.uk allegedly wrote:
Yeah, I know, but this is specifically for me logging into a box via SSH and sending a file "home", ie to me, so I have some control over the checks which take place on the incoming mail.
Forgive me, I'm curious.
If you have ssh access to this machine and just want to send a couple of files back home, why do you want to use SMTP as the file transport mechanism?
Mick
Indeed, makes little sense to use SMTP when SSH is available.
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Steven Rose wrote:
mbm wrote:
If you have ssh access to this machine and just want to send a couple of files back home, why do you want to use SMTP as the file transport mechanism?
Indeed, makes little sense to use SMTP when SSH is available.
Indeed, I do use scp a lot in these situations.
However, there is one situation which has occurred recently where this was not possible/easy.
I have a box on a site where the only access I have to it is to join a VPN, use it to connect via VNC to a Windows PC from which I use PuTTY to connect to the box. The Windows box is "secured" (I use that term advisedly :-) and I can't install anything else on it or transfer files from it (in any way I've found so far - I can't even open Windows Explorer on it). However the box does have Internet access and I could scp to an Internet facing server and then pull it down to my PC via scp, but that's messy.
The file I need to get is only a few kB in size so email is sensible. In many cases I am connecting to the box to get a file to subsequently email on to someone else anyway, so it would make sense to email from the box rather than jump through hoops in order to email it from my desktop.
I've also been in situations where I am on site and want to send a file home; again scp is not an option unless using the 2-step approach.
In all of these cases scp does provide a workaround but the "simplest" option would be to email the file home from the server.
Mark Rogers mark@quarella.co.uk wrote: [...]
I have a box on a site where the only access I have to it is to join a VPN, use it to connect via VNC to a Windows PC from which I use PuTTY to connect to the box. The Windows box is "secured" [...] In all of these cases scp does provide a workaround but the "simplest" option would be to email the file home from the server.
I'm wondering how emailing that data in the clear would fit in with the "security" policies around that machine, but there's nowt as queer as Windows admins. I think the above has demonstrated how constrained the solution space is!
Regards,
MJ Ray wrote:
Mark Rogers mark@quarella.co.uk wrote: [...]
I have a box on a site where the only access I have to it is to join a VPN, use it to connect via VNC to a Windows PC from which I use PuTTY to connect to the box. The Windows box is "secured" [...]
I'm wondering how emailing that data in the clear would fit in with the "security" policies around that machine, but there's nowt as queer as Windows admins.
The security is intended to stop me messing around on their network, just giving me access to the one box that I can pretty much do what I like with. How well that security works in practise I have no idea, I'm not in the habit of trying to h^Hcrack my customers networks! That said, most of the network functionality disabled/hidden on the Windows box is available to me on that same network via the Linux box.
I didn't set the constraints nor do I have any opinion on them, I just have to work within them.
On Wed, 15 Oct 2008 15:37:43 +0100 Mark Rogers mark@quarella.co.uk allegedly wrote:
The security is intended to stop me messing around on their network, just giving me access to the one box that I can pretty much do what I like with. How well that security works in practise I have no idea, I'm not in the habit of trying to h^Hcrack my customers networks! That said, most of the network functionality disabled/hidden on the Windows box is available to me on that same network via the Linux box.
Interesting security policy.
I didn't set the constraints
of course not.
nor do I have any opinion on them,
I bet you do. :-)
Mick
---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
-
Brett Parker -
Chris G -
Jon Dye -
Mark Rogers -
mbm -
MJ Ray -
Steven Rose