kmail command line options

I can't seem to get mail to work, but I've got kmail working fine from the gui interface, anyway. How can I get kmail to send a file from the command line? When I try something like:

cat file | kmail -s "Subject" my_email_address
--or--
kmail -s "Subject" --msg msg_file my_email_address

...the kmail client window pops open all loaded and ready to send but waiting for me to click the "send" button. I want it to go ahead and do the send automatically, so this can be done from a script. Surely kmail will allow this...?

Thanks.

Why does mail not work? Are you using your localhost to sendmail?

Try to use the "mail", "mailx" or "sendmail" command instead.

It's a bit useless to load all the KDE libraries, widgets, themes, and other bloat if you want to send an e-mail. (besides that, it requires KDE)

Thanks, guys. I don't have mailx on my Red Hat Linux installation. I can get elm and mail and sendmail to attempt to send mail, and finally, after playing around with the sendmail.cf file I have managed to trick my ISP's mail server, mail.bellsouth.net, into RETURNING the mail messages I send as undeliverable to my POP3 account (so I can receive it on my Windows machine).

The problem after a days' experimentation seems to be: How do I get past the error "553 Linux.myserver.com does not exist".

It seems that because mail.bellsouth.net can't look up the name I gave my Linux box, it refuses to accept or forward my emails. Do I need to trick it somehow, or is this simply an indication that they want me to have a registered domain before they will deliver my mail when generated from my domain?

If so, how can I get around this rule? I pay Bellsouth $50/mo. for the DSL service and the email, so why should it matter that I want to send email from a Linux box?

Side note: The kmail client is working fine, both ways (of all things!), but it is unsatisfactory for my purposes because I have to use it interactively, and can't pass it a message to send from a script.

try: /usr/sbin/sendmail -t -oi -odq < message.txt

(or "cat message.txt | /usr/sbin/sendmail -t -oi -odq", but this would win the "useless use of cat award")

The message should also contain the valid SMTP headers, for example

From: someone<someone@nowhere.com>
To: myself<me@somewhere.com>
Subject: message test

hello :-)

sendmail will fetch the MX-record of an Internet domain, and deliver e-mail directly to the SMTP-server of that domain You don't need your ISP to deliver e-mail, since you're running your own MTA.

If you're seriously thinking about running an MTA, or mail-server, I'd suggest using 'postfix' instead of sendmail. postfix is a lot easier to configure, and has less vulnerabilities. postfix in 99.9% sendmail compatible.

That is EXACTLY what I needed to know! I was able to accomplish my purpose my wrong-headed way by changing the name of my machine to mail.bellsouth.net, which tricked the bellsouth mail server into letting the mail go through. Apparently, sendmail, by default identifies itself to outside mail servers and BellSouth doesn't like my machine.domainname.com because it's not registered (I'm guessing). Using my method, my emails passed their validitiy checking, I suppose.

But YOUR method works beautifully, and now I can change my machine name and domain back to what they should be. As you can tell, I am a sendmail novice.

Thanks SO much for your help. I'll go look at those sendmail options, because I want to understand what you mean about my MTA not needing my ISP to deliver mail. If I understand you correctly, my emails (which WERE going out) should not have been returned by the BellSouth mail server. I want to understand why those were coming back doing it the way I was before.

Originally posted by randyasu Thanks SO much for your help. I'll go look at those sendmail options, because I want to understand what you mean about my MTA not needing my ISP to deliver mail. If I understand you correctly, my emails (which WERE going out) should not have been returned by the BellSouth mail server. I want to understand why those were coming back doing it the way I was before.

You're welcome.

For now I won't bother you with any details about how SMTP servers operate, or how e-mail is actually sent ....because it's great to read how you can't wait to investigate this yourself. Bravo.

Originally posted by yapp You're welcome. For now I won't bother you with any details about how SMTP servers operate, or how e-mail is actually sent ....because it's great to read how you can't wait to investigate this yourself. Bravo.

Ah' Tooo Bad;
I'm enjoying this thread, please lay it down! I find this very interesting;

OK, here's the update. Using sendmail with the options above was working fine. Everything was just the way I wanted it. The script was debugged and the cron was set up. Our emails were going out fine. So...

I changed the name of my host and domain back from mail.bellsouth.net to Linux.mydomain.com and now the email is going out somewhere, but when it tries to get to my (Windows machine's) email via mail.bellsouth.net it gets rejected by the
"reason: 553 Linux.mydomain.com does not exist"
check. Is BellSouth's mail server trying to validate my domain before it delivers the mail to me? I mean, that sounds like a good idea from the standpoint of anti-spam and all, but how can I get past this without registering my site and paying for a permanent IP address (plus $15/mo. more to Bellsouth for a fixed IP)? I really feel like I'm spoofing the mail.bellsouth.net server the other way.

If nobody has any other ideas, tomorrow I'm going to try spoofing as some other mail server and see if that works...

Originally posted by micxz Ah' Tooo Bad; I'm enjoying this thread, please lay it down! I find this very interesting;

sorry all right, here is the story I'd typed it already..



To send e-mail, you connect to an MTA (mail transfer agent), or what you would call an SMTP server. Whether it's located at home, or at your ISP doesn't really matter. The MTA uses DNS to find the MX (Mail-eXchange) record of the receivers domain, and contacts that SMTP server. It will exchange details about it's domain, sender / receiver address, and will pass the message (again with headers).

Then, that second MTA tries to deliver the message. If it's mailbox is located at it's own server, it will drop the messages in the mailbox, and otherwise, pass it to "real" destination (for example an internal network).. this chain continues until the message is actually delivered. Think again about those "Received:" headers in your e-mail message, and you'll quickly realize what they are all about.

At UNIX, your local mailbox is usually something like /var/spool/mail, or ~/Maildir. If you run a SMTP server in your own domain, you could actually receive messages directly. Messages will be received at port 25 (smtp), and dropped in /var/spool/mail, or ~/Maildir. As alternative, your ISP provides you these facilities. They have their own "/var/spool/mail", and you can use POP3 to fetch those messages. Their servers are up 24/7 to receive your e-mail.

MTA's will try to deliver a message to the next hop in 5 days, and otherwise, send a bounce-mail back to the sender-address.


About running an MTA yourself: consider the problems if one could use your MTA to send spam, etc... You need to know what you're doing. If you'd like to run a MTA yourself, I'd strongly suggest to use Postfix. Sendmail is big, complex, hard to configure and had too much vulnerabilities in the past. (yet e-mail exists because of sendmail)

Originally posted by randyasu ...but when it tries to get to my (Windows machine's) email via mail.bellsouth.net it gets rejected by the "reason: 553 Linux.mydomain.com does not exist" check.

Could you explain this part a little more? I find it a little confusing.

If you want to have a "domain name", try no-ip.org. They offer free DNS services, that will return your IP-address, if someone queries them about something.no-ip.org ...and offer an auto-update tool if your IP address changes.

You could try to send the e-mail from a telnet session. (this is really cool). It allows you to discover at which point the message is not accepted, and it's a little easier to test, then trying to alter the sendmail configuration

You need to type this:

$ telnet smtp-server 25
HELO your domain
MAIL FROM: <your email>
RCPT TO: <recipient address>

* also type the < and > characters
* multiple RCPT TO commands are allowed
* type RSET to reset if you make a typo...

DATA
mail headers; from, to, subject (if you omit them, some headers will be generated automatically)
blank line
message contents...
.

* yes at the end, type a single dot at an empty line
* the message will be queued for delivery.

* You could type another MAIL FROM:, etc... (sometimes type RSET first) for the next message.

* to close the connection, type:
QUIT

this is exactly what your e-mail program does when it's sending e-mail. Maybe you can understand how easy viruses can pretend to send e-mail from another address, since you're just telling who you are..