Hot answers tagged

34

Short Answer: You can't. For more info, this gives a basic explaination as to why. This shows how easy it is to do. It's just the nature of SMTP, it's insecure! Just because an email appears to come from somebody, it doesn't mean it did.


25

You could set up SPF records for your email domains, however this will only have a limited effect, if any.


15

As long as you bounce the mail by refusing to receive it in the first place, then a spammer cannot use you to annoy somebody innocent with a lot of bounces. You can either return an error on the RCPT TO command, which is what usually happens in case of a non-existent address, or you can return success on the RCPT TO command but return an error at the end of ...


13

They recommend to keep retrying and eventually the IP should get greylisted. We've configured our Postfix to do this. All bounced emails get retried a few times but Mimecast is not removing us off their greylist. If you will forgive me, I'm not sure you quite understand greylisting. As Mimecraft's docs say, the identifier for a greylisting decision ...


12

Tech support is wrong. There is nothing you can do to stop someone else sending email as if it came from your account(s). Only the receiving system can do anything about it. Measures such as SPF, DKIM and the like help the receiving systems validate senders but such things are not a requirement by any standards and those systems which enforce such things are ...


10

If it's being blocked due to an SPF record, then ideally they need to correct their SPF records to include their sending MX hosts. The reason it will be blocked by your mail servers and not others is purely down the configuration of mail servers or relays in your organisation to honor SPF records of the sender. Other organisations chose not to honor SPF. ...


9

it should be immediately rejected. Senders mail server should inform the sender about failure with non-delivery report.


8

Ubuntu-1004-lucid-64-minimal is not a valid global name, tell postfix to use your "real" domain name, using the myhostname setting: http://www.postfix.org/postconf.5.html#myhostname


8

To receive emails from other servers, you need to be listening on port 25. Port 587 is the submission port, intended for clients to submit mail for delivery. Other mail servers will never try to connect to this port.


8

Based on the information you've provided, this is almost certainly not coming from your server unless you run an open relay. The message originated in China: inetnum: 123.112.0.0 - 123.127.255.255 netname: UNICOM-BJ descr: China Unicom Beijing province network descr: China Unicom country: CN admin-c: CH1302-...


7

What I usually do is set up a mail forwarder as a backup MX - that is, a mail server that isn't the destination for any emails but can hold on to them (leave them on hold) in case something goes wrong. The upside to this is that the moment your main mail server goes back up the emails start being delivered as if nothing happened - you don't have multiple ...


7

The mail server mx.maxus.pl attempted to look up the domain name in the From: email address, aquarius@aquariusprams.co.uk, and was unable to find it. This means your recipient's mail server is having trouble resolving domain names correctly, as I was able to look this up successfully. The problem is with the recipient's mail system, not with your Google ...


7

As RFC3463 explains, status codes beginning with 5 are used for permanent failures and 4 for persistent transient failures. Instead of trying to parse several messages with different formats you could rely on server logs and try something like this: grep " dsn=5." /var/log/mail.log | grep -o -P " to=<(.+?)>" | sort | uniq -c This will find permanent ...


6

As others have said, you can't stop the spammer from using your address or do much to prevent the receiver from sending you a bounce. Those receiving servers are already misconfigured at least one way: they should have rejected the message without accepting it. That would make it the sender's job to produce a bounce, which the spam software is not going ...


6

Accoding to the answers given at http://stackoverflow.com/questions/386294/what-is-the-maximum-length-of-a-valid-email-address The answer is 254 according to RFC 5321 So, those MTA are badly configured.


6

I'm going to make this answer fairly generic because the terminology and configuration details will vary depending on your specific mail server/spam filter software. There are actually 3 approaches for an invalid recipient: After the recipient is determined to be invalid, send an Undeliverable message back to the sender. Close the SMTP connection while ...


5

Frankly the best way is not to do mass emails from anything remotely related to your domain. By definition anything unsolicited mass emailed is spam. If it's solicited then the recipients will whitelist it.


5

Have a look at the Powershell Dig Cmdlet. Using this you are able to do this: PS> $allRecords = Get-Dns -Name mydomain.com -Type MX PS> write-host $allRecords.RecordsMX $allRecords is of type PoshNet.Dns.Response so you can read the properties on it to get your records. Something else nice about this cmdlet is that you can have it return multiple ...


5

Hand this responsibility over to somebody else. Postini, AppRiver, and Symantec are all examples of companies that do this for you. Let them filter your spam before it gets to your network and spool your email should your server go down. It's much better than putting together your own solution which could also go down (like if you have an extended internet ...


5

As per the RFC 2821, an NDR has to be sent to the "reverse-path" address specified with the MAIL FROM: command during the SMTP dialogue: If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" ...


5

In the log you posted: Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL FROM command)) The previous owner of your IP address sent junk mail from it, and Hotmail has banned it. Try putting your IP ...


5

The return path for bounces is determined by the envelope sender (the MAIL FROM line in the smtp protocol). In the mail headers this is generally copied to the Return-Path header. Here's an example of a mailing list mail that specifies bounces should go to the mailing list server instead of the sender of the mail: Return-Path: <git-owner@vger.kernel.org&...


5

We got bounce message from 118.69.183.136. But why does it bounce to both manager1@gmail.com and manager2@gmail.com? Did they both send an email, which could not be delivered? Unlikely. It isn't bouncing to the two addresses, it's bouncing it to postmaster telling you that delivery to those two addresses failed. Then google replies with "421-4.7.0 [16.19....


5

Generally there are two types of bounces The bounces caused by directrejection of remote mail server when your postfix deliver the email. The bounces caused by remote server (next-hop server after your postfix) fails to deliver the message to final recipients. The first case was already covered by excellent answer by Esa Jokinen above. Your best bet is ...


5

You cannot compel others to filter their incoming mail based on SPF and DKIM, or indeed any other criteria at all. If google chooses to ignore SPF, so be it; you've done your bit, all you can do now is sit tight and ignore any complaints from people who don't filter on SPF. That said, having a valid SPF record does tend to reduce backscatter, because a ...


5

The problem seems to be that you have other servers than your mail server listed in your MX record, one of which has a lower priority. MX records work on a lowest-priority-first basis, which means the internet is first of all trying to send mail for your domain to smtp.secureserver.net., which doesn't seem to know anything about your domain. At this point, ...


4

If you are expecting your mail to be reliably delivered, then a soft fail is not good. Your message may still be delivered depending on the policy of the receiving system. For the best chance of successful delivery you should update your SPF record so the message you are trying to send is permitted.


4

Out-Of-Office replies do usually get sent via return-path, yes. It's correct to the RFC specs, too. More info here: http://tools.ietf.org/html/rfc3834


4

A hard bounce is an indication that you should never send a message to that address. The bounce message should contain an indication as to why you were bounced. If the address does not exist, then no amount of waiting is likely to resolve the issue. If you get a soft bounce, such as you should get for over quota, use an exponential backoff. This should ...


4

function Get-DnsAddressList { param( [parameter(Mandatory=$true)][Alias("Host")] [string]$HostName) try { return [System.Net.Dns]::GetHostEntry($HostName).AddressList } catch [System.Net.Sockets.SocketException] { if ($_.Exception.ErrorCode -ne 11001) { throw $_ } return = @() ...



Only top voted, non community-wiki answers of a minimum length are eligible