I need to setup a file distribution system between different sites of a WAN. Files that are dropped into some input directories on the source machine should be distributed into a directory on each of the target machines at other sites. One of the requirements is that between certain sites the only allowed traffic is SMTP. There is already a daemon in place that covers the sending side by polling input directories and mailing all found files as attachments to configured addresses (was thought for human recipients originally).
How would you design the receiving side?
One could write a stripped down SMTP server that handles only this one case, strips attachments from incoming mails, and puts them into a local directory.
One could setup a full mail server with local delivery, poll the user’s inbox and try to extract files from there.
One could setup a full mail server with a configuration or procmail to directly extract attachments into a directory.
I don’t really like any of these proposals because they are all more involved than setting up a SSH or FTP server. Also I don’t have experience with setting up and administrating mail servers.
Do you have suggestions or experiences to share?
The target system is Linux/Unix, but if you know something platform independent I’d like to hear, too.
The most suitable way is to set up an ESB with SMTP support, like ServiceMix or Mule. Mule is more straight-forward to get started with.
Related
I want to set up a ticketing system (osTicket) on a centOS server that generates tickets from incoming e-mails.
osTicket can query mailboxes, but it also provides an API / scripts for piping. Is there a recommended way to setup a (lightweight) mailserver to pipe incoming emails to the script? I do not need actual mailboxes for users.
It's been a while since I did any work on a mail server, but it seems to me that I would only need to set up an MTA for this, and no MDA, correct?
My fallback is to set up POP3/SMTP inboxes elsewhere and query from osTicket. Easy as that would be, the local MTA setup seems cleaner to me.
Consider using remote mailbox accessible via IMAP with IMAP IDLE command support.
It will allow you to get "near real time" delivery to pipe without burden of configuring properly your own SMTP server.
[AFAIR IMAP IDLE is supported e.g. by gmail]
You may use fetchmail with custom procmail script as mda (no need for local SMTP/MTA server).
Using procmail (as "man in the middle) is not strictly necessary but your it will allow you to easily run filtering before delivery to the ticket system (e.g. anti-spam + anti-virus).
EDIT: I have not used the wrong mail reader, but my exim was no configured correctly. So I go and check that first. I used exim quite out-of-the-box in gentoo linux.
Original Question:
It's a bit hard to google, since the word mail means much more than just the unix command mail.
I want to run a local exim that spools most of the mail just locally. I want to read that mail with something like mail from commandline.
Now, exim does not use /var/spool/mail and not the same spooling format, so mail just finds no new mails.
So my question: how should I combine a simple mail client with exim, and which simple mail client is able to do so?
Check your exim.conf file to see which transports are delivering local messages. It will look something like this (from an Ubuntu machine):
mail_spool:
debug_print = "T: appendfile for $local_part#$domain"
driver = appendfile
file = /var/mail/$local_part
delivery_date_add
envelope_to_add
return_path_add
group = mail
mode = 0660
mode_fail_narrower = false
Also go look in your mail logs, somewhere under /var/log. Find where it's actually delivering the messages by finding what transport it's using to deliver them. It will be in the delivery line (the one containing "=>" to the local user) and will be of the format T=transport_name. You can look at that transport definition in exim.conf to determine where it's delivering them if you can't figure out where the emails are being delivered from the log messages.
Alternative: Every distro has the mutt MUA available as well (CentOS installs it by default). You might find it easier to install and configure mutt to read the mail spool wherever it is being delivered, than to try and re-work whatever custom changes your distro made to exim and its local mail spool delivery. Common delivery locations are:
/var/mail/$USER
$HOME/Maildir/
$HOME/.maildir/
Note that the presence of a trailing slash when defining mail spools usually indicates that the mailbox is in Maildir++ format (i.e. one file per message). The absence of that slash usually indicates that the mailbix is in mbox format (i.e. one big file).
What tools are available to generate bounce messages in order to test a bounce management tool? We want to test invalid addresses but we will like to test other error status codes.
It sounds to me like you want an SMTP server that generates such errors in a reliable fashion.
Lots of open-source SMTP servers exist and are available for modification. One option is Apache James, a modular open-source Java SMTP server.
A much more trivial test server could simply open port 25 for receiving mails, and deliver canned errors depending on configuration (or incoming email).
I want to write some email scanning software and don't understand how to setup my server. I have a hosted web server running Windows 2003 Server. It is running the Default SMTP Virtual Server with a fully-qualified domain name of abcdef.com (example). DNS is pointing abcdef.com to my server. If I spoof an email from my desktop pc so that it appears to come from info#abcdef.com, and I send the email to a 'non-existant' email address then the bounceback does arrive on my web server and is stored in C:\inetpub\mailroot\Queue on the server - great! (I can scan it and handle the bounceback). However, if I simply send an email straight to info#abcdef.com then it does not seem to get placed anywhere on the server. I don't understand why bouncebacks get stored but other incoming email doesn't. I'm keen to avoid having to install any 'email server software' on the server, as I want to keep things as clean as possible. All I really want is some way of telling the server to accept all incoming messages to abcdef.com so that I can process them myself, and to place the .eml files in a known directory that I can scan. I'll then write an eml file parser to process the files.
Thanks very much.
A possible reason for the lack of delivery is that your domain has a DNS A record, but no DNS MX record. MX records are used for delivery of mail. Historically, if no MX record was present for a domain, mail servers were supposed to fall back to looking for a domain's A record.
In your case, I'd guess that your local mail-sending software is looking for an MX record and then stopping if it doesn't find one, whereas the remote system sending you the bounce is looking for the MX record and then looking for an A record when it can't find one.
The Wikipedia article on MX records has more details.
SMTP is a message transfer agent (MTA), responsible only for handling the transfer of mail from one point (the client, perhaps) to another (the mailbox server, such as a POP or IMAP server). SMTP servers aren't the right tool for ultimately handling mail coming INTO a domain -- they only handle transferring the mail coming into a domain to another app, such as the aforementioned POP or IMAP server, which then know how to sort and store that mail.
In short, the Default SMTP Virtual Server isn't the tool you're looking for for your project.
From this other StackOverflow question, it looks like there are a few SMTP servers which are intended for development use but which might serve the purpose you seek -- they accept incoming messages and then write them to files (in some manner, and with some tweaking).
Ok, working now. Issues were as follows:
There was no MX record, so external email wasn't being directed to the server. The .EML file that existed on the server was indeed placed there by an outbound email process.
The firewall was blocking port 25 - now opened.
It is necessary to have some sort of inbound email service running on the server. Windows Server has a lightweight POP3 service which you can configure to place all incoming email into a single 'catch-all' mailbox. This fills with .EML files, which can then be scanned by our custom service.
Many thanks to delfuego & Jon.
I regularly send files in Gmail to exchange files between different computers. It is cumbersome. I want quickly to send my files, such as error logs. I found a promising article [1] about Mutt, but it apparently is not what I want:
Please note that mutt is a pure MUA
and cannot send e-mail without proper
email server .
I want no email server, since I cannot install it to my clients' computers. I don't need to know the sender. I want quickly to send many error logs to my Gmail. I am looking something like:
mutt -s "Many error logs" -a
./log1 -a ./log2 -a ./log3 mygmail#gmail.com
I would really love to do the job in terminal. It is too time-consuming to bulk-send files in Gmail. How can I quickly send a great amount of files?
[1] http://www.cyberciti.biz/tips/sending-mail-with-attachment.html
Mutt can be configured to use a different MTA than the default sendmail. You could install SSMTP (described here and available for download here) or ESMTP and configure it to send directly to Gmail's web server, then configure Mutt to use SSMTP or ESMTP. This is nicely described in this Ubuntu tutorial. If installing systemwide binaries isn't an option, you ought to be able to install SSMTP or ESMTP to a local folder.
If you prefer scripting, mimesend, which is one of the example programs in Perl's MIME-tools package, does the same thing as your mutt command and could be hacked to connect to Gmail's web server.
Why are you using email for this? Other options:
FTP/SCP (run a server yourself, or purchase a hosted service)
Internet storage service like Dropbox.
assuming that you don't want to use ftp/scp as suggested above, here is how i solved a similar problem ... emailing logs from a client:
i created a cgi script on my server that had the ability to mail things to myself. a sort of email proxy webservice.
the client posted the files it needed to send (along with authentication, obviously) to that cgi script.
that way the client only needs to talk to my server instead of talking to a mail server.
perhaps this helps.
-don