Linux mail not sending

/usr/bin/mail call in ExecStart not sending any mail

For some reason, that mail command never sends any mail when the scollector process exits with non-0. This works AOK when run on the command line, /bin/sh call and all. I’ve captured STDOUT and STDERR of mail , and it is throwing no errors. There is nothing in maillog . What gives? Why won’t it send mail?

Yeah, you’re correct. I ended up not using any of the above, so I never ran into that exit . I’ll fix it in the question regardless so it doesn’t red-herring anyone.

try ExecStart=/bin/sh -c «false || (echo » | /usr/bin/mail -s ‘scollector died’ jharvey@stackoverflow.com && exit -1)» . Does it work? Which version of systemd are you using?

Nope. As indicated in my answer, the issue is caused by systemd nuking the double-forked sendmail call from mail . I’m on cent7, which uses systemd 208 .

To reiterate: simply having ExecStart=/bin/sh -c «/usr/bin/mail -s test me@gmail.com

2 Answers 2

/usr/bin/mail performs a double fork to daemonize sendmail for sending the email. This sendmail proc gets reowned to init , so normally it wouldn’t be affected by anything that happens with the original parent — except in the systemd case that reowned grandchild is still in the same cgroup as the original service. When systemd tears things down, it kills all processes within the cgroup, including the reowned sendmail process.

The mail command itself ran fine, but sendmail was getting killed by systemd before it had a chance to do its thing.

You can get around this by setting KillMode in the Unit section to process (the default is control-group ). That will cause systemd to only kill the process which it directly fired.

Interestingly the way I stumbled upon this was through the use of strace . A normal strace revealed nothing, but the mail suddenly started working when using strace -f . strace -f was causing the main process to stick around until all of the children and orphaned grandchildren had wrapped up.

Источник

Common Linux email problems and how to fix them

Email servers and clients occasionally like to rebel and every sysadmin needs to know how to quell the uprising.

Great Linux resources

When working with email, you never know what to expect. The issues that system administrators come across vary from place to place, from person to person, and from server to server. However, there are issues that remain the same everywhere. In my personal experience, I have seen many mailing issues across the board; from millions of spam emails filling up the mail queue and the server’s disk space (and ultimately taking down the server), to phishing emails from hacked websites with honeypots sending emails to other customers on the same network. In this article, we will cover common email problems that occur in the world of system administration.

Email delays

The first thing you want to do when troubleshooting email delays is to get the information you need in order to troubleshoot. Having the information that you need to get started, or at least information to work from, helps you to make an informed decision. Let’s say that there is an email that did not go through to the recipient, or that bounced back to the original sender. The best information to start with is the full email headers of the email that was sent to the original sender. Depending on the mail client you are using, you can gather the mail ID from the mail header in different ways, but it is always available, regardless of the client. Once you have the mail ID, you can search for the ID in the mail logs with the following command:

$ grep 'EMAIL ID' /var/log/exim_mainlog 

If you are not familiar with the way the logs are formatted, you could overlook important information. Reading the output logs is definitely something that can require a trained eye and will get easier with experience. Over time, the logs can serve as more than just information, but as a source of truth.

Outlook error codes

Mail clients commonly throw out error codes when things go wrong—and they do go wrong. Outlook can be notorious for this issue, so going over the most common Outlook error codes is a must.

Invalid HELO: 0x800CCC78

Outlook almost always sends an invalid HELO, and as a result, must directly authenticate (vs. the IP auth from checking IMAP/POP) to bypass the check. You receive the 0x800CCC78 error code in this situation. If this error is hit by a client sending email, it’s a result of SMTP authentication not being set up or set up incorrectly. When a user is authenticated, most SMTP checks are bypassed.

The official description from Microsoft states:

Your sender address must be a full email address not simply a username. Please set up your account in Outlook/Outlook Express to use a full account name such as username@mydomain.com instead of simply ‘username’.

Note: An Invalid HELO message is not specific to Outlook. Only the error code is.

The host could not be found: 0x800CCC0D

The full version of this error looks like this:

The host 'mail.domain.com' could not be found. Please verify that you have entered the server name correctly. Error Number: 0x800CCC0D 

If you see this error, there could be a problem with the mail server that the mail client is attempting to connect to. The mail server could be propagating its DNS record, misspelled, or having resolution/network problems. This issue requires investigation of the mail server as a system administrator. As an alternative to the mail server’s domain, you can also use the mail server’s IP address.

The connection to the server has failed: 0x800CCC0E

This error means that there is a problem with the incoming port: port 110 should be used for POP3, and port 143 should be used for IMAP. Separate ports are used for secure connections that require SSL. That information is covered in more depth in A sysadmin’s guide to configuring an email server.

An unknown error has occurred: 0x800CCC69

The full version of this error looks like:

An unknown error has occurred. Subject 'test', Account: 'mail.domain.com', Server: 'mail.domain.com', Protocol: SMTP, Server Response: '550 External MTA's must be authenticated in order to send e-mails', Port: 25, Secure(SSL): No, Server Error: 550, Error Number: 0x800CCC69 

In this error, it states that the mail transfer agent has to be authenticated in order to send email. That is because mail clients and servers need to verify the source and destinations to avoid being marked as potential spam. In order to do that, the outgoing mail server or client needs to enable authentication, which can be set up in the mail client. Specific settings for Outlook can be found here.

Guess which error: 0x800CCC67

This error code is tricky, as it can mean a couple of different things. If you use port 25 for SMTP, it might be blocked. It is common for mail services and ISPs to block them. The problem could also be another firewall that is installed locally on the sender’s workstation and blocking SMTP connections. Or, Outlook could also just be set up incorrectly. To find the culprit just requires troubleshooting.

SMTP firewall errors

In most shared environments, ports 25 and 26 are blocked for non-root users to prevent abuse. This includes but is not limited to spammy scripts sending excessive amounts of email from the server (resulting in server or IP blacklisting) and email deliverability issues for all clients on the machine.

There are multiple ways around this problem:

1. Use the Sendmail binary or PHPMailer instead.
   You might choose to use the Sendmail binary or PHPMailer instead. In some cases, you will need to specifically set the FROM setting in the SMTP envelope when using this option. Otherwise, the Sender would be the server’s default email address, not the proper one.
2. Use the domain or server’s IP as the hostname and port 26 as the outgoing port.
   This setup requires email authentication for the SMTP server and logging in with the username and password. It’s recommended to set the FROM setting here as well. The FROM header is what is normally seen by the receiver (unless the receiver chooses to view full headers).
3. Whitelist the user in the firewall.
   You can whitelist a user or IP through the firewall. This tactic is only recommended as a last resort. Once the rules are added, restarting the firewall is a good best practice. Adding the user or IP through the firewall will allow them to connect to any host on the available outgoing ports, like 25 and 26.

No such person at this address

Rejections with the error of «No such person at this address,» or another custom message, are usually due to a forward being set up to reject email. The regular fail message is «No Such User Here,» but some clients use other messages. You can set up custom messages on the mail server and configure them to match what suits the situation best. However, the default seems to work just fine.

SPF rejection

Incoming email is usually checked for a valid Sender Policy Framework (SPF) record when the destination address an authentication checker enabled. Neutral or failed SPF checks result in bounces, which can also have custom messages just like «No such person» errors. All of the rejection messages are customizable. SPF is used to indicate to mail exchanges which hosts are authorized to send mail for a domain. The record is easy to create and works well. There are control panels that allow you to create such a record with a user-friendly tool, or you can make one with an online tool, or create a record from memory.

Email pipes/forwarding

Email pipes need to begin with binary to PHP (e.g., /usr/local/bin/php ). This process sends an email message to a program and appends the message to the mailbox file with real-time delivery. Just as with the option of setting up an SPF rejection, you have additional options for how the email pipes can be set up and how they will work. This tactic is at the mercy of wherever the mail server is located.

Conclusion

There are still so many more mailing issues that exist. There is no way to cover them all. This article is meant to give you insight and shine a light into the world of mailing issues, what to look out for, and how to solve them. The most common issue across these different problems is that something will happen at some point, and having authentication is always a good idea.

[ Want more on networking topics? Check out the Linux networking cheat sheet. ]

Источник

Unix mail command not sending email

Check —config-verbose option is available if -v is not the correct option tag. This will show you the pipeline your setup is using for configuration file locations.

4 Answers 4

So, it’s probably at least one thing, possibly two.

1. You need to enable the mail service. On the latest MacOSX, postfix is installed by default. You just need to run ‘sudo launchctl start org.postfix.master’ to start the postfix server. That’ll just temporarily start it for your current session. Check to see if any mail can be sent. Look in /var/log/mail.log.
2. If mail can’t be sent out via port 25 (for example, comcast blocks outgoing port 25), you’ll need to configure postfix to deliver mail through either Comcast’s SMTP service or via some other SMTP server.

It works when I’m at home, but it doesn’t work at the university which is where I want to use it. I suspect it’s a blocked port or something. I’ve tried following the instructions in the link, but that didn’t work.

1) Use man mail to check if your mail program supports -v command line option (verbose mode). It should provide ore hints.

echo "something" | mail -v -s "test mail" email@address.com 

2) Check log entries generated by your MTA/mail server (postfix/sendmail/exim/. )

Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.

Make sure you’ve correctly configured the SMTP settings in your mailing daemon configuration file

Need also to set up that whoever is supposed to relay mail does so. That is usually disabled to limit spam.

in one word your locan mail transfer agent which is mightly something like root@localhost.com is not recognized as a trusted and well known address to any exchange(mail.google or mail.yahoo) server. so they easily block it.

The mail subsystem does not appear to be fully or correctly configured. If you know, how to configure it on the running Mac OS X, drop a note.

You must log in to answer this question.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.13.43531

Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group.
This site is not affiliated with Linus Torvalds or The Open Group in any way.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник