Incoming mail from sender, MX record won't accept replies. How to block the incoming SMTP connection from that sender? The 2019 Stack Overflow Developer Survey Results Are InTroubleshooting 5.5.0 smtp; 503 Bad sequence of commands (Microsoft SMTP + Exchange 2003)Will ISPs accept mail from a postfix null client with no dns recordPostfix rewrites senderHow is incoming SMTP mail being delivered despite blocked portIs it still “wrong” to require STARTTLS on incoming SMTP messagesdeny an email from sender at one of my mx records, so it tries the other mx recordSMTP Options for our dedicated that does not include having to change the smtp in the mail client to sendHow to configure Postfix SMTP to mail to another server from external client?postfix restrict mail relay for certain sender addresses (“MAIL FROM:”) onlyPOSTFIX cant connect from SMTP with TLS
How to type a long/em dash `—`
What is this business jet?
What is preventing me from simply constructing a hash that's lower than the current target?
Is it safe to harvest rainwater that fell on solar panels?
What is the meaning of Triage in Cybersec world?
How to obtain a position of last non-zero element
If a sorcerer casts the Banishment spell on a PC while in Avernus, does the PC return to their home plane?
How come people say “Would of”?
Does adding complexity mean a more secure cipher?
Why does the nucleus not repel itself?
Did Scotland spend $250,000 for the slogan "Welcome to Scotland"?
Why “相同意思的词” is called “同义词” instead of "同意词"？
What could be the right powersource for 15 seconds lifespan disposable giant chainsaw?
Why are there uneven bright areas in this photo of black hole?
Are there any other methods to apply to solving simultaneous equations?
Straighten subgroup lattice
How to support a colleague who finds meetings extremely tiring?
Deal with toxic manager when you can't quit
How did passengers keep warm on sail ships?
Correct punctuation for showing a character's confusion
What to do when moving next to a bird sanctuary with a loosely-domesticated cat?
The difference between dialogue marks
How to display lines in a file like ls displays files in a directory?
writing variables above the numbers in tikz picture
Incoming mail from sender, MX record won't accept replies. How to block the incoming SMTP connection from that sender?
The 2019 Stack Overflow Developer Survey Results Are InTroubleshooting 5.5.0 smtp; 503 Bad sequence of commands (Microsoft SMTP + Exchange 2003)Will ISPs accept mail from a postfix null client with no dns recordPostfix rewrites senderHow is incoming SMTP mail being delivered despite blocked portIs it still “wrong” to require STARTTLS on incoming SMTP messagesdeny an email from sender at one of my mx records, so it tries the other mx recordSMTP Options for our dedicated that does not include having to change the smtp in the mail client to sendHow to configure Postfix SMTP to mail to another server from external client?postfix restrict mail relay for certain sender addresses (“MAIL FROM:”) onlyPOSTFIX cant connect from SMTP with TLS
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
How do I block an SMTP connection when I determine the sender's MX record will reject mail?
That is, if the advertised (MX record) way to send mail back to the domain will in fact not work, I want to reject the incoming SMTP connection.
I'm administrating a mail service for a small business. They have a mail host, foo.example.org, whose internet connection is an ADSL service with a permanent IP address.
Unfortunately, many mail systems are misconfigured in the following way:
- the sending host,
bar.example.com, will happily deliver tofoo.example.org, and - the DNS for
bar.example.comhas an MX record listing the host (mail.example.com) to which mail should be directed for that domain; but - the specified host
mail.example.comrejects SMTP connections fromfoo.example.org.
So the declared sender's domain has an MX which refuses to receive connections from this host. That misconfiguration makes their system a one-way mail sender, which is a problem.
Note that I'm not, as some commenters have assumed, talking about hosts which only send mail; that's not the problem. The misconfiguration is in that domain's mail system, declaring a sender domain for the message when that domain's MX won't accept SMTP connections from the domain to which you're sending.
I have also confirmed the DNS configuration is correct (with A and PTR records that map correctly both ways) and confirmed the host's IP address is not blacklisted in many of the reputable blacklist services, with helpful links from JohnnyD.
Those mail systems that are rejecting this host seem to be doing so primarily because it's on an ADSL service, regardless of the fact that it has a permanently-assigned IP address and is not listed in reputable lists of dynamic IP addresses (because it's a permanently-assigned address).
How can I configure Postfix on this customer's mail host to refuse SMTP sessions that declare a sender domain which itself refuses SMTP from this host? That is, if the SMTP client declares a domain that we can't make SMTP connections back to, then there's not much point accepting the incoming connection in the first place.
I'm imagining a late check (after the low-cost checks to winnow most of the rubbish connections) that keeps the client on the other end while it attempts an SMTP client connection back to the declared domain of the sender. If that connection is rejected, the incoming one is also rejected.
Yes, that means some mail might be blocked. But that's better than accepting the message, and then not having a way to reply or tell the sender there's a problem at their end. By blocking the message at SMTP time, the sender will at least receive prompt notification, which isn't the case now.
I'm also open to other suggestions for how this problem might be addressed (short of not using this mail host, which isn't an option).
postfix smtp
asked Jun 9 '10 at 3:47
bignosebignose
622416
add a comment |
How do I block an SMTP connection when I determine the sender's MX record will reject mail?
That is, if the advertised (MX record) way to send mail back to the domain will in fact not work, I want to reject the incoming SMTP connection.
I'm administrating a mail service for a small business. They have a mail host, foo.example.org, whose internet connection is an ADSL service with a permanent IP address.
Unfortunately, many mail systems are misconfigured in the following way:
- the sending host,
bar.example.com, will happily deliver tofoo.example.org, and - the DNS for
bar.example.comhas an MX record listing the host (mail.example.com) to which mail should be directed for that domain; but - the specified host
mail.example.comrejects SMTP connections fromfoo.example.org.
So the declared sender's domain has an MX which refuses to receive connections from this host. That misconfiguration makes their system a one-way mail sender, which is a problem.
Note that I'm not, as some commenters have assumed, talking about hosts which only send mail; that's not the problem. The misconfiguration is in that domain's mail system, declaring a sender domain for the message when that domain's MX won't accept SMTP connections from the domain to which you're sending.
I have also confirmed the DNS configuration is correct (with A and PTR records that map correctly both ways) and confirmed the host's IP address is not blacklisted in many of the reputable blacklist services, with helpful links from JohnnyD.
Those mail systems that are rejecting this host seem to be doing so primarily because it's on an ADSL service, regardless of the fact that it has a permanently-assigned IP address and is not listed in reputable lists of dynamic IP addresses (because it's a permanently-assigned address).
How can I configure Postfix on this customer's mail host to refuse SMTP sessions that declare a sender domain which itself refuses SMTP from this host? That is, if the SMTP client declares a domain that we can't make SMTP connections back to, then there's not much point accepting the incoming connection in the first place.
I'm imagining a late check (after the low-cost checks to winnow most of the rubbish connections) that keeps the client on the other end while it attempts an SMTP client connection back to the declared domain of the sender. If that connection is rejected, the incoming one is also rejected.
Yes, that means some mail might be blocked. But that's better than accepting the message, and then not having a way to reply or tell the sender there's a problem at their end. By blocking the message at SMTP time, the sender will at least receive prompt notification, which isn't the case now.
I'm also open to other suggestions for how this problem might be addressed (short of not using this mail host, which isn't an option).
postfix smtp
asked Jun 9 '10 at 3:47
bignosebignose
622416
1
Just something to consider - One of our web sites is an on-line store, so it sends a fair number of emails (order confirmations and the like). However, that system will not receive emails. If our customers implemented what you are proposing the whole system would be worthless.
– John Gardeniers
Jun 9 '10 at 3:51
I fail to see how you have come to the conclusion that the "other" mail server is misconfigured because it won't accept email from your server. Many entities use different servers for sending and receiving email. My worry is that your lack of understanding of the nuances of email transport may cause undesired results, like users not receiving emails.
– joeqwerty
Jun 9 '10 at 4:53
So basically, the next time I fat finger my mail server and accidentally break inbound mail, you'll compound the situation by rejecting my outgoing mail too?
– Jed Daniels
Jul 2 '10 at 1:17
While it is totally bogus to reject an entire range of IP addresses based on the fact that they are ADSL, it is equally bogus to reject an entire class of senders who reject you. Two wrongs and all that...
– Jed Daniels
Jul 2 '10 at 1:21
add a comment |
How do I block an SMTP connection when I determine the sender's MX record will reject mail?
That is, if the advertised (MX record) way to send mail back to the domain will in fact not work, I want to reject the incoming SMTP connection.
I'm administrating a mail service for a small business. They have a mail host, foo.example.org, whose internet connection is an ADSL service with a permanent IP address.
Unfortunately, many mail systems are misconfigured in the following way:
- the sending host,
bar.example.com, will happily deliver tofoo.example.org, and - the DNS for
bar.example.comhas an MX record listing the host (mail.example.com) to which mail should be directed for that domain; but - the specified host
mail.example.comrejects SMTP connections fromfoo.example.org.
So the declared sender's domain has an MX which refuses to receive connections from this host. That misconfiguration makes their system a one-way mail sender, which is a problem.
Note that I'm not, as some commenters have assumed, talking about hosts which only send mail; that's not the problem. The misconfiguration is in that domain's mail system, declaring a sender domain for the message when that domain's MX won't accept SMTP connections from the domain to which you're sending.
I have also confirmed the DNS configuration is correct (with A and PTR records that map correctly both ways) and confirmed the host's IP address is not blacklisted in many of the reputable blacklist services, with helpful links from JohnnyD.
Those mail systems that are rejecting this host seem to be doing so primarily because it's on an ADSL service, regardless of the fact that it has a permanently-assigned IP address and is not listed in reputable lists of dynamic IP addresses (because it's a permanently-assigned address).
How can I configure Postfix on this customer's mail host to refuse SMTP sessions that declare a sender domain which itself refuses SMTP from this host? That is, if the SMTP client declares a domain that we can't make SMTP connections back to, then there's not much point accepting the incoming connection in the first place.
I'm imagining a late check (after the low-cost checks to winnow most of the rubbish connections) that keeps the client on the other end while it attempts an SMTP client connection back to the declared domain of the sender. If that connection is rejected, the incoming one is also rejected.
Yes, that means some mail might be blocked. But that's better than accepting the message, and then not having a way to reply or tell the sender there's a problem at their end. By blocking the message at SMTP time, the sender will at least receive prompt notification, which isn't the case now.
I'm also open to other suggestions for how this problem might be addressed (short of not using this mail host, which isn't an option).
postfix smtp
asked Jun 9 '10 at 3:47
bignosebignose
622416
How do I block an SMTP connection when I determine the sender's MX record will reject mail?
That is, if the advertised (MX record) way to send mail back to the domain will in fact not work, I want to reject the incoming SMTP connection.
I'm administrating a mail service for a small business. They have a mail host, foo.example.org, whose internet connection is an ADSL service with a permanent IP address.
Unfortunately, many mail systems are misconfigured in the following way:
- the sending host,
bar.example.com, will happily deliver tofoo.example.org, and - the DNS for
bar.example.comhas an MX record listing the host (mail.example.com) to which mail should be directed for that domain; but - the specified host
mail.example.comrejects SMTP connections fromfoo.example.org.
So the declared sender's domain has an MX which refuses to receive connections from this host. That misconfiguration makes their system a one-way mail sender, which is a problem.
Note that I'm not, as some commenters have assumed, talking about hosts which only send mail; that's not the problem. The misconfiguration is in that domain's mail system, declaring a sender domain for the message when that domain's MX won't accept SMTP connections from the domain to which you're sending.
I have also confirmed the DNS configuration is correct (with A and PTR records that map correctly both ways) and confirmed the host's IP address is not blacklisted in many of the reputable blacklist services, with helpful links from JohnnyD.
Those mail systems that are rejecting this host seem to be doing so primarily because it's on an ADSL service, regardless of the fact that it has a permanently-assigned IP address and is not listed in reputable lists of dynamic IP addresses (because it's a permanently-assigned address).
How can I configure Postfix on this customer's mail host to refuse SMTP sessions that declare a sender domain which itself refuses SMTP from this host? That is, if the SMTP client declares a domain that we can't make SMTP connections back to, then there's not much point accepting the incoming connection in the first place.
I'm imagining a late check (after the low-cost checks to winnow most of the rubbish connections) that keeps the client on the other end while it attempts an SMTP client connection back to the declared domain of the sender. If that connection is rejected, the incoming one is also rejected.
Yes, that means some mail might be blocked. But that's better than accepting the message, and then not having a way to reply or tell the sender there's a problem at their end. By blocking the message at SMTP time, the sender will at least receive prompt notification, which isn't the case now.
I'm also open to other suggestions for how this problem might be addressed (short of not using this mail host, which isn't an option).
postfix smtp
postfix smtp
asked Jun 9 '10 at 3:47
bignosebignose
622416
asked Jun 9 '10 at 3:47
bignosebignose
622416
edited yesterday
bignose
asked Jun 9 '10 at 3:47
bignosebignose
622416
asked Jun 9 '10 at 3:47
bignosebignose
622416
asked Jun 9 '10 at 3:47
bignosebignose
622416
622416
1
Just something to consider - One of our web sites is an on-line store, so it sends a fair number of emails (order confirmations and the like). However, that system will not receive emails. If our customers implemented what you are proposing the whole system would be worthless.
– John Gardeniers
Jun 9 '10 at 3:51
I fail to see how you have come to the conclusion that the "other" mail server is misconfigured because it won't accept email from your server. Many entities use different servers for sending and receiving email. My worry is that your lack of understanding of the nuances of email transport may cause undesired results, like users not receiving emails.
– joeqwerty
Jun 9 '10 at 4:53
So basically, the next time I fat finger my mail server and accidentally break inbound mail, you'll compound the situation by rejecting my outgoing mail too?
– Jed Daniels
Jul 2 '10 at 1:17
While it is totally bogus to reject an entire range of IP addresses based on the fact that they are ADSL, it is equally bogus to reject an entire class of senders who reject you. Two wrongs and all that...
– Jed Daniels
Jul 2 '10 at 1:21
add a comment |
1
Just something to consider - One of our web sites is an on-line store, so it sends a fair number of emails (order confirmations and the like). However, that system will not receive emails. If our customers implemented what you are proposing the whole system would be worthless.
– John Gardeniers
Jun 9 '10 at 3:51
I fail to see how you have come to the conclusion that the "other" mail server is misconfigured because it won't accept email from your server. Many entities use different servers for sending and receiving email. My worry is that your lack of understanding of the nuances of email transport may cause undesired results, like users not receiving emails.
– joeqwerty
Jun 9 '10 at 4:53
So basically, the next time I fat finger my mail server and accidentally break inbound mail, you'll compound the situation by rejecting my outgoing mail too?
– Jed Daniels
Jul 2 '10 at 1:17
While it is totally bogus to reject an entire range of IP addresses based on the fact that they are ADSL, it is equally bogus to reject an entire class of senders who reject you. Two wrongs and all that...
– Jed Daniels
Jul 2 '10 at 1:21
1
1
Just something to consider - One of our web sites is an on-line store, so it sends a fair number of emails (order confirmations and the like). However, that system will not receive emails. If our customers implemented what you are proposing the whole system would be worthless.
– John Gardeniers
Jun 9 '10 at 3:51
Just something to consider - One of our web sites is an on-line store, so it sends a fair number of emails (order confirmations and the like). However, that system will not receive emails. If our customers implemented what you are proposing the whole system would be worthless.
– John Gardeniers
Jun 9 '10 at 3:51
I fail to see how you have come to the conclusion that the "other" mail server is misconfigured because it won't accept email from your server. Many entities use different servers for sending and receiving email. My worry is that your lack of understanding of the nuances of email transport may cause undesired results, like users not receiving emails.
– joeqwerty
Jun 9 '10 at 4:53
I fail to see how you have come to the conclusion that the "other" mail server is misconfigured because it won't accept email from your server. Many entities use different servers for sending and receiving email. My worry is that your lack of understanding of the nuances of email transport may cause undesired results, like users not receiving emails.
– joeqwerty
Jun 9 '10 at 4:53
So basically, the next time I fat finger my mail server and accidentally break inbound mail, you'll compound the situation by rejecting my outgoing mail too?
– Jed Daniels
Jul 2 '10 at 1:17
So basically, the next time I fat finger my mail server and accidentally break inbound mail, you'll compound the situation by rejecting my outgoing mail too?
– Jed Daniels
Jul 2 '10 at 1:17
While it is totally bogus to reject an entire range of IP addresses based on the fact that they are ADSL, it is equally bogus to reject an entire class of senders who reject you. Two wrongs and all that...
– Jed Daniels
Jul 2 '10 at 1:21
While it is totally bogus to reject an entire range of IP addresses based on the fact that they are ADSL, it is equally bogus to reject an entire class of senders who reject you. Two wrongs and all that...
– Jed Daniels
Jul 2 '10 at 1:21
add a comment |
9 Answers
9
active
oldest
votes
I would start by doing a thourgh check of all composite blocking lists:
MyIpTest.com
Barracuda Central
Anti-Abuse Project - enter IP in Multi-RBL Check textbox on right
UCEProtect-Network
Let me know how you make out.
answered Jun 9 '10 at 14:46
JohnyDJohnyD
1,25621629
1
The address is no doubt listed as “belongs to a range of addresses assigned to ADSL service”. While true, these lists appear to be misused as “nobody should ever be making SMTP connections from these addresses”, which is an abuse of the list; the address is permanently assigned to this service and is valid for use. So, the problem is the misconfiguration of the remote server blocking this address, not the list itself.
– bignose
Jun 9 '10 at 22:08
2
Unfortunately, yes, it is a valid reason, sorry. You may request that this pool of addresses be removed from the list of dynamic addresses, you should work in cooperation with your ISP.
– silk
Jun 10 '10 at 20:32
Thanks for the links, JohnnyD. The mail host's address gets a clear report from all of those services, so we can be confident it's not listed in a reputable blacklist.
– bignose
Jun 11 '10 at 2:52
A very thorough blacklist-checking service (147 blacklists, ATM) is at mxtoolbox.com/blacklists.aspx.
– user70549
Mar 11 '11 at 6:06
add a comment |
What do you suppose is the most parsimonious explanation:
- "Many" mail systems are misconfigured
because they won't accept mail from
you. - "Many" mail systems won't accept mail
from you because your system is
misconfigured.
I'm leaning toward the second option. Even if it were the first, it's still bad form to punish the other networks for daring to not accept mail from you. Wouldn't it be more productive to find out the root of the problem?
I suspect that one or both of the following are true:
- Your DNS settings are screwed up.
Let's say your SMTP server is mail.example.com. You need to make
sure that your DNS servers have an A
record mapping to mail.example.com,
that mail.example.com is listed as an
MX server for example.com, and (this
is the big one) your ISP's DNS
servers have an rDNS record mapping your public IP address back
to mail.example.com. As a spam
countermeasure, many mail servers
won't accept inbound connections from
IP addresses that fail these DNS
tests. - There is a spam-spewing
bot on the LAN, so your IP address
has been blacklisted.
answered Jun 9 '10 at 8:34
dbc labdbc lab
542
The explicit reason given, in a majority of these cases, is “your host is on an ADSL connection”. That's true, but seems to imply that the address is dynamic, which is false. To block merely because the client is assigned to an ADSL range is a misconfiguration.
– bignose
Jun 9 '10 at 22:04
1
"To block merely because the client is assigned to an ADSL range is a misconfiguration." No, this is a feature of a particular anti-spam technique. They aren't making assumptions about DHCP, they are making (rational) assumptions about consumer-grade circuits (from which they see a lot of spam). All that the recipients want is for you to configure DNS settings that you ought to have configured anyway. Why wouldn't you want your rDNS entry to be correct?
– dbc lab
Jun 11 '10 at 6:11
Where have you got the impression that the DNS entries are incorrect? They're not; PTR and A records are present and correct. Also, the recipients have made plain that their reason for rejection is not poorly-configured DNS settings, but rather that ADSL is the criterion on which they're rejecting.
– bignose
Jun 13 '10 at 5:07
"Where have you got the impression that the DNS entries are incorrect?" The fact that you specifically mention A and PTR records, but you ignore rDNS, is a good indication you've messed up there.
– dbc lab
Jun 13 '10 at 15:42
One of us is very confused. I answered your questions about rDNS. Do you think rDNS uses something other than PTR records?
– bignose
Jun 14 '10 at 7:23
|
show 3 more comments
Doing what you propose here will likely eventually result in you no longer receiving email from the biggest and most widely used domains in the world (gmail, hotmail, yahoo, etc.).
I'm also open to other suggestions for
how this problem might be addressed
(short of not using this mail host at
all, which isn't an option).
The first thing I'd try is to make sure the PTR record for your IP matches your domain, and does not resolve to something like "user1235.big-isp-adsl-for-the-masses.com".
But ultimately, and I know this answer sucks, I think the only thing you are going to be able to do to properly send to those domains that currently reject you is to get a new IP address for your mail host. I know, it isn't fair. And I strongly urge you to fight the good fight. But when you get tired of your mail getting lost sporadically, then I think you'll decide that getting a new IP is what you've gotta do (or bite the bullet and move to a different server/host that works).
answered Jul 2 '10 at 1:35
Jed DanielsJed Daniels
5,9792739
Thanks. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end.
– bignose
Jul 2 '10 at 12:26
add a comment |
i am VERY recommend you to find freshest instruction for antispam or your mail server became spam-botted within 2 days.
and "refusing SMTP sessions that declare a sender domain which itself refuses SMTP" is not enough!
it`s from my own experience :( (but for another mailer)
answered Jun 9 '10 at 4:21
evg345evg345
36614
Thanks, but this doesn't address what I've written. The mail server is existing for a while, and has adequate protection against unsolicited junk. I'm talking about adding a new restriction onto an existing mail server.
– bignose
Jun 9 '10 at 6:13
add a comment |
You could use ppolicy to add new policies. You will probably need to write your own module, but it should be do-able
https://bimbo.fjfi.cvut.cz/ppolicy/browser/trunk/README
answered Jun 9 '10 at 12:21
Pablo MartinezPablo Martinez
1,8661110
add a comment |
Check http://www.spamhaus.org/pbl/ list.
If it is there, and it is a static address, you will be able to remove it.
answered Jun 11 '10 at 8:35
silksilk
823513
That is one of the black lists included in the aggregate checks suggested in JohnnyD's answer. The address is not currently listed at that service.
– bignose
Jun 13 '10 at 2:21
add a comment |
Spamhaus and/or greylisting will drop most of the problem addresses. Requiring FQDN in the helo/ehlo messages will catch a lot of the rest.
Dropping messages from servers which don't accept messages won't work if they also do the same. There are a number of legitimate senders who don't accept bounce messages after the fact.
Bounce the message during the connection not afterwards or you will contribute to SPAM through backscatter.
DNS and rDNS need to agree for your server. If your address is listed as dynamic at Spamhaus, you will be refused by a large number of servers, mine included.
answered Jul 2 '10 at 3:32
BillThor BillThor
24.8k22662
Senders don't themselves have to accept mail, but they do need to have an MX record. If the sender's MX host refuses mail, I don't want to accept the incoming connection from the sender in the first place.
– bignose
May 8 '11 at 1:53
@bignose: There are a number of legitmate mailing list and autmated senders who do NOT accept e-mail in any form either at the address or their MX. This is bad form, but gets rid of all the spam they are likely to get. If you don't mind dropping these mail sources, you can drop senders you can't reply to. Howver, callouts to some of the big freemail senders can get your reputation with them downgraded (again bad form).
– BillThor
May 8 '11 at 18:28
“If you don't mind dropping these mail sources, you can drop senders you can't reply to.” Yes, that's exactly what this question is asking. If you know how to do that, please write an answer!
– bignose
May 12 '11 at 3:26
@bignose Exim provides a verify_sender condition for ACLs. I limit it to sroute checking, as checking senders drops legitimate mail my user want. There are options to check for a valid postmaster or random userids. See exim.org/exim-html-current/doc/html/spec_html/… for details.
– BillThor
May 12 '11 at 13:41
add a comment |
Can you set up your mailserver to pass all outbound mail to an upstream host (at the ISP, or a separate paid service) that's not blacklisted?
Does your customer know you're proposing/working on an approach that's going to result in them not getting inbound E-mail from their customers? I think the "bounce mail from people who discriminate against ADSL SMTP senders" policy is going to cause confusion for your customer (who will get phone calls asking about the bounces) and ultimately make their system(s) less useful, which is hard to justify.
answered Jul 2 '10 at 6:18
gbroilesgbroiles
1,20487
Thanks. Currently, senders succeed in getting a message delivered, but then there's no way to reply back. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end. That will be an improvement over the current situation.
– bignose
Jul 2 '10 at 12:27
add a comment |
It dawned on me. You keep mentioning MX records, but those are not what you're looking for. The DNS feature you want to leverage is the TXT record with the SPF line.
https://en.wikipedia.org/wiki/Sender_Policy_Framework
This allows you to whitelist IPs that are allowed to send mail for that domain. But be careful, you can easily cut yourself off if you fail to whitelist your ISP's SMTP relay or if it changes.
And after knowing the name of what we want, finding articles is easy:
https://www.howtoforge.com/postfix_spf
answered 2 days ago
ZdenekZdenek
1324
Yes, MX records – the incoming domain's advertised way for that domain to receive mail – are what I'm looking for (and I've now clarified this in the question, thank you). SPF addresses an entirely different problem, so this answer doesn't apply.
– bignose
yesterday
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f149495%2fincoming-mail-from-sender-mx-record-wont-accept-replies-how-to-block-the-inco%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
I would start by doing a thourgh check of all composite blocking lists:
MyIpTest.com
Barracuda Central
Anti-Abuse Project - enter IP in Multi-RBL Check textbox on right
UCEProtect-Network
Let me know how you make out.
answered Jun 9 '10 at 14:46
JohnyDJohnyD
1,25621629
1
The address is no doubt listed as “belongs to a range of addresses assigned to ADSL service”. While true, these lists appear to be misused as “nobody should ever be making SMTP connections from these addresses”, which is an abuse of the list; the address is permanently assigned to this service and is valid for use. So, the problem is the misconfiguration of the remote server blocking this address, not the list itself.
– bignose
Jun 9 '10 at 22:08
2
Unfortunately, yes, it is a valid reason, sorry. You may request that this pool of addresses be removed from the list of dynamic addresses, you should work in cooperation with your ISP.
– silk
Jun 10 '10 at 20:32
Thanks for the links, JohnnyD. The mail host's address gets a clear report from all of those services, so we can be confident it's not listed in a reputable blacklist.
– bignose
Jun 11 '10 at 2:52
A very thorough blacklist-checking service (147 blacklists, ATM) is at mxtoolbox.com/blacklists.aspx.
– user70549
Mar 11 '11 at 6:06
add a comment |
I would start by doing a thourgh check of all composite blocking lists:
MyIpTest.com
Barracuda Central
Anti-Abuse Project - enter IP in Multi-RBL Check textbox on right
UCEProtect-Network
Let me know how you make out.
answered Jun 9 '10 at 14:46
JohnyDJohnyD
1,25621629
1
The address is no doubt listed as “belongs to a range of addresses assigned to ADSL service”. While true, these lists appear to be misused as “nobody should ever be making SMTP connections from these addresses”, which is an abuse of the list; the address is permanently assigned to this service and is valid for use. So, the problem is the misconfiguration of the remote server blocking this address, not the list itself.
– bignose
Jun 9 '10 at 22:08
2
Unfortunately, yes, it is a valid reason, sorry. You may request that this pool of addresses be removed from the list of dynamic addresses, you should work in cooperation with your ISP.
– silk
Jun 10 '10 at 20:32
Thanks for the links, JohnnyD. The mail host's address gets a clear report from all of those services, so we can be confident it's not listed in a reputable blacklist.
– bignose
Jun 11 '10 at 2:52
A very thorough blacklist-checking service (147 blacklists, ATM) is at mxtoolbox.com/blacklists.aspx.
– user70549
Mar 11 '11 at 6:06
add a comment |
I would start by doing a thourgh check of all composite blocking lists:
MyIpTest.com
Barracuda Central
Anti-Abuse Project - enter IP in Multi-RBL Check textbox on right
UCEProtect-Network
Let me know how you make out.
answered Jun 9 '10 at 14:46
JohnyDJohnyD
1,25621629
I would start by doing a thourgh check of all composite blocking lists:
MyIpTest.com
Barracuda Central
Anti-Abuse Project - enter IP in Multi-RBL Check textbox on right
UCEProtect-Network
Let me know how you make out.
answered Jun 9 '10 at 14:46
JohnyDJohnyD
1,25621629
answered Jun 9 '10 at 14:46
JohnyDJohnyD
1,25621629
answered Jun 9 '10 at 14:46
JohnyDJohnyD
1,25621629
answered Jun 9 '10 at 14:46
JohnyDJohnyD
1,25621629
1,25621629
1
The address is no doubt listed as “belongs to a range of addresses assigned to ADSL service”. While true, these lists appear to be misused as “nobody should ever be making SMTP connections from these addresses”, which is an abuse of the list; the address is permanently assigned to this service and is valid for use. So, the problem is the misconfiguration of the remote server blocking this address, not the list itself.
– bignose
Jun 9 '10 at 22:08
2
Unfortunately, yes, it is a valid reason, sorry. You may request that this pool of addresses be removed from the list of dynamic addresses, you should work in cooperation with your ISP.
– silk
Jun 10 '10 at 20:32
Thanks for the links, JohnnyD. The mail host's address gets a clear report from all of those services, so we can be confident it's not listed in a reputable blacklist.
– bignose
Jun 11 '10 at 2:52
A very thorough blacklist-checking service (147 blacklists, ATM) is at mxtoolbox.com/blacklists.aspx.
– user70549
Mar 11 '11 at 6:06
add a comment |
1
The address is no doubt listed as “belongs to a range of addresses assigned to ADSL service”. While true, these lists appear to be misused as “nobody should ever be making SMTP connections from these addresses”, which is an abuse of the list; the address is permanently assigned to this service and is valid for use. So, the problem is the misconfiguration of the remote server blocking this address, not the list itself.
– bignose
Jun 9 '10 at 22:08
2
Unfortunately, yes, it is a valid reason, sorry. You may request that this pool of addresses be removed from the list of dynamic addresses, you should work in cooperation with your ISP.
– silk
Jun 10 '10 at 20:32
Thanks for the links, JohnnyD. The mail host's address gets a clear report from all of those services, so we can be confident it's not listed in a reputable blacklist.
– bignose
Jun 11 '10 at 2:52
A very thorough blacklist-checking service (147 blacklists, ATM) is at mxtoolbox.com/blacklists.aspx.
– user70549
Mar 11 '11 at 6:06
1
1
The address is no doubt listed as “belongs to a range of addresses assigned to ADSL service”. While true, these lists appear to be misused as “nobody should ever be making SMTP connections from these addresses”, which is an abuse of the list; the address is permanently assigned to this service and is valid for use. So, the problem is the misconfiguration of the remote server blocking this address, not the list itself.
– bignose
Jun 9 '10 at 22:08
The address is no doubt listed as “belongs to a range of addresses assigned to ADSL service”. While true, these lists appear to be misused as “nobody should ever be making SMTP connections from these addresses”, which is an abuse of the list; the address is permanently assigned to this service and is valid for use. So, the problem is the misconfiguration of the remote server blocking this address, not the list itself.
– bignose
Jun 9 '10 at 22:08
2
2
Unfortunately, yes, it is a valid reason, sorry. You may request that this pool of addresses be removed from the list of dynamic addresses, you should work in cooperation with your ISP.
– silk
Jun 10 '10 at 20:32
Unfortunately, yes, it is a valid reason, sorry. You may request that this pool of addresses be removed from the list of dynamic addresses, you should work in cooperation with your ISP.
– silk
Jun 10 '10 at 20:32
Thanks for the links, JohnnyD. The mail host's address gets a clear report from all of those services, so we can be confident it's not listed in a reputable blacklist.
– bignose
Jun 11 '10 at 2:52
Thanks for the links, JohnnyD. The mail host's address gets a clear report from all of those services, so we can be confident it's not listed in a reputable blacklist.
– bignose
Jun 11 '10 at 2:52
A very thorough blacklist-checking service (147 blacklists, ATM) is at mxtoolbox.com/blacklists.aspx.
– user70549
Mar 11 '11 at 6:06
A very thorough blacklist-checking service (147 blacklists, ATM) is at mxtoolbox.com/blacklists.aspx.
– user70549
Mar 11 '11 at 6:06
add a comment |
What do you suppose is the most parsimonious explanation:
- "Many" mail systems are misconfigured
because they won't accept mail from
you. - "Many" mail systems won't accept mail
from you because your system is
misconfigured.
I'm leaning toward the second option. Even if it were the first, it's still bad form to punish the other networks for daring to not accept mail from you. Wouldn't it be more productive to find out the root of the problem?
I suspect that one or both of the following are true:
- Your DNS settings are screwed up.
Let's say your SMTP server is mail.example.com. You need to make
sure that your DNS servers have an A
record mapping to mail.example.com,
that mail.example.com is listed as an
MX server for example.com, and (this
is the big one) your ISP's DNS
servers have an rDNS record mapping your public IP address back
to mail.example.com. As a spam
countermeasure, many mail servers
won't accept inbound connections from
IP addresses that fail these DNS
tests. - There is a spam-spewing
bot on the LAN, so your IP address
has been blacklisted.
answered Jun 9 '10 at 8:34
dbc labdbc lab
542
The explicit reason given, in a majority of these cases, is “your host is on an ADSL connection”. That's true, but seems to imply that the address is dynamic, which is false. To block merely because the client is assigned to an ADSL range is a misconfiguration.
– bignose
Jun 9 '10 at 22:04
1
"To block merely because the client is assigned to an ADSL range is a misconfiguration." No, this is a feature of a particular anti-spam technique. They aren't making assumptions about DHCP, they are making (rational) assumptions about consumer-grade circuits (from which they see a lot of spam). All that the recipients want is for you to configure DNS settings that you ought to have configured anyway. Why wouldn't you want your rDNS entry to be correct?
– dbc lab
Jun 11 '10 at 6:11
Where have you got the impression that the DNS entries are incorrect? They're not; PTR and A records are present and correct. Also, the recipients have made plain that their reason for rejection is not poorly-configured DNS settings, but rather that ADSL is the criterion on which they're rejecting.
– bignose
Jun 13 '10 at 5:07
"Where have you got the impression that the DNS entries are incorrect?" The fact that you specifically mention A and PTR records, but you ignore rDNS, is a good indication you've messed up there.
– dbc lab
Jun 13 '10 at 15:42
One of us is very confused. I answered your questions about rDNS. Do you think rDNS uses something other than PTR records?
– bignose
Jun 14 '10 at 7:23
|
show 3 more comments
What do you suppose is the most parsimonious explanation:
- "Many" mail systems are misconfigured
because they won't accept mail from
you. - "Many" mail systems won't accept mail
from you because your system is
misconfigured.
I'm leaning toward the second option. Even if it were the first, it's still bad form to punish the other networks for daring to not accept mail from you. Wouldn't it be more productive to find out the root of the problem?
I suspect that one or both of the following are true:
- Your DNS settings are screwed up.
Let's say your SMTP server is mail.example.com. You need to make
sure that your DNS servers have an A
record mapping to mail.example.com,
that mail.example.com is listed as an
MX server for example.com, and (this
is the big one) your ISP's DNS
servers have an rDNS record mapping your public IP address back
to mail.example.com. As a spam
countermeasure, many mail servers
won't accept inbound connections from
IP addresses that fail these DNS
tests. - There is a spam-spewing
bot on the LAN, so your IP address
has been blacklisted.
answered Jun 9 '10 at 8:34
dbc labdbc lab
542
The explicit reason given, in a majority of these cases, is “your host is on an ADSL connection”. That's true, but seems to imply that the address is dynamic, which is false. To block merely because the client is assigned to an ADSL range is a misconfiguration.
– bignose
Jun 9 '10 at 22:04
1
"To block merely because the client is assigned to an ADSL range is a misconfiguration." No, this is a feature of a particular anti-spam technique. They aren't making assumptions about DHCP, they are making (rational) assumptions about consumer-grade circuits (from which they see a lot of spam). All that the recipients want is for you to configure DNS settings that you ought to have configured anyway. Why wouldn't you want your rDNS entry to be correct?
– dbc lab
Jun 11 '10 at 6:11
Where have you got the impression that the DNS entries are incorrect? They're not; PTR and A records are present and correct. Also, the recipients have made plain that their reason for rejection is not poorly-configured DNS settings, but rather that ADSL is the criterion on which they're rejecting.
– bignose
Jun 13 '10 at 5:07
"Where have you got the impression that the DNS entries are incorrect?" The fact that you specifically mention A and PTR records, but you ignore rDNS, is a good indication you've messed up there.
– dbc lab
Jun 13 '10 at 15:42
One of us is very confused. I answered your questions about rDNS. Do you think rDNS uses something other than PTR records?
– bignose
Jun 14 '10 at 7:23
|
show 3 more comments
What do you suppose is the most parsimonious explanation:
- "Many" mail systems are misconfigured
because they won't accept mail from
you. - "Many" mail systems won't accept mail
from you because your system is
misconfigured.
I'm leaning toward the second option. Even if it were the first, it's still bad form to punish the other networks for daring to not accept mail from you. Wouldn't it be more productive to find out the root of the problem?
I suspect that one or both of the following are true:
- Your DNS settings are screwed up.
Let's say your SMTP server is mail.example.com. You need to make
sure that your DNS servers have an A
record mapping to mail.example.com,
that mail.example.com is listed as an
MX server for example.com, and (this
is the big one) your ISP's DNS
servers have an rDNS record mapping your public IP address back
to mail.example.com. As a spam
countermeasure, many mail servers
won't accept inbound connections from
IP addresses that fail these DNS
tests. - There is a spam-spewing
bot on the LAN, so your IP address
has been blacklisted.
answered Jun 9 '10 at 8:34
dbc labdbc lab
542
What do you suppose is the most parsimonious explanation:
- "Many" mail systems are misconfigured
because they won't accept mail from
you. - "Many" mail systems won't accept mail
from you because your system is
misconfigured.
I'm leaning toward the second option. Even if it were the first, it's still bad form to punish the other networks for daring to not accept mail from you. Wouldn't it be more productive to find out the root of the problem?
I suspect that one or both of the following are true:
- Your DNS settings are screwed up.
Let's say your SMTP server is mail.example.com. You need to make
sure that your DNS servers have an A
record mapping to mail.example.com,
that mail.example.com is listed as an
MX server for example.com, and (this
is the big one) your ISP's DNS
servers have an rDNS record mapping your public IP address back
to mail.example.com. As a spam
countermeasure, many mail servers
won't accept inbound connections from
IP addresses that fail these DNS
tests. - There is a spam-spewing
bot on the LAN, so your IP address
has been blacklisted.
answered Jun 9 '10 at 8:34
dbc labdbc lab
542
edited Jun 9 '10 at 8:57
answered Jun 9 '10 at 8:34
dbc labdbc lab
542
answered Jun 9 '10 at 8:34
dbc labdbc lab
542
answered Jun 9 '10 at 8:34
dbc labdbc lab
542
542
The explicit reason given, in a majority of these cases, is “your host is on an ADSL connection”. That's true, but seems to imply that the address is dynamic, which is false. To block merely because the client is assigned to an ADSL range is a misconfiguration.
– bignose
Jun 9 '10 at 22:04
1
"To block merely because the client is assigned to an ADSL range is a misconfiguration." No, this is a feature of a particular anti-spam technique. They aren't making assumptions about DHCP, they are making (rational) assumptions about consumer-grade circuits (from which they see a lot of spam). All that the recipients want is for you to configure DNS settings that you ought to have configured anyway. Why wouldn't you want your rDNS entry to be correct?
– dbc lab
Jun 11 '10 at 6:11
Where have you got the impression that the DNS entries are incorrect? They're not; PTR and A records are present and correct. Also, the recipients have made plain that their reason for rejection is not poorly-configured DNS settings, but rather that ADSL is the criterion on which they're rejecting.
– bignose
Jun 13 '10 at 5:07
"Where have you got the impression that the DNS entries are incorrect?" The fact that you specifically mention A and PTR records, but you ignore rDNS, is a good indication you've messed up there.
– dbc lab
Jun 13 '10 at 15:42
One of us is very confused. I answered your questions about rDNS. Do you think rDNS uses something other than PTR records?
– bignose
Jun 14 '10 at 7:23
|
show 3 more comments
The explicit reason given, in a majority of these cases, is “your host is on an ADSL connection”. That's true, but seems to imply that the address is dynamic, which is false. To block merely because the client is assigned to an ADSL range is a misconfiguration.
– bignose
Jun 9 '10 at 22:04
1
"To block merely because the client is assigned to an ADSL range is a misconfiguration." No, this is a feature of a particular anti-spam technique. They aren't making assumptions about DHCP, they are making (rational) assumptions about consumer-grade circuits (from which they see a lot of spam). All that the recipients want is for you to configure DNS settings that you ought to have configured anyway. Why wouldn't you want your rDNS entry to be correct?
– dbc lab
Jun 11 '10 at 6:11
Where have you got the impression that the DNS entries are incorrect? They're not; PTR and A records are present and correct. Also, the recipients have made plain that their reason for rejection is not poorly-configured DNS settings, but rather that ADSL is the criterion on which they're rejecting.
– bignose
Jun 13 '10 at 5:07
"Where have you got the impression that the DNS entries are incorrect?" The fact that you specifically mention A and PTR records, but you ignore rDNS, is a good indication you've messed up there.
– dbc lab
Jun 13 '10 at 15:42
One of us is very confused. I answered your questions about rDNS. Do you think rDNS uses something other than PTR records?
– bignose
Jun 14 '10 at 7:23
The explicit reason given, in a majority of these cases, is “your host is on an ADSL connection”. That's true, but seems to imply that the address is dynamic, which is false. To block merely because the client is assigned to an ADSL range is a misconfiguration.
– bignose
Jun 9 '10 at 22:04
The explicit reason given, in a majority of these cases, is “your host is on an ADSL connection”. That's true, but seems to imply that the address is dynamic, which is false. To block merely because the client is assigned to an ADSL range is a misconfiguration.
– bignose
Jun 9 '10 at 22:04
1
1
"To block merely because the client is assigned to an ADSL range is a misconfiguration." No, this is a feature of a particular anti-spam technique. They aren't making assumptions about DHCP, they are making (rational) assumptions about consumer-grade circuits (from which they see a lot of spam). All that the recipients want is for you to configure DNS settings that you ought to have configured anyway. Why wouldn't you want your rDNS entry to be correct?
– dbc lab
Jun 11 '10 at 6:11
"To block merely because the client is assigned to an ADSL range is a misconfiguration." No, this is a feature of a particular anti-spam technique. They aren't making assumptions about DHCP, they are making (rational) assumptions about consumer-grade circuits (from which they see a lot of spam). All that the recipients want is for you to configure DNS settings that you ought to have configured anyway. Why wouldn't you want your rDNS entry to be correct?
– dbc lab
Jun 11 '10 at 6:11
Where have you got the impression that the DNS entries are incorrect? They're not; PTR and A records are present and correct. Also, the recipients have made plain that their reason for rejection is not poorly-configured DNS settings, but rather that ADSL is the criterion on which they're rejecting.
– bignose
Jun 13 '10 at 5:07
Where have you got the impression that the DNS entries are incorrect? They're not; PTR and A records are present and correct. Also, the recipients have made plain that their reason for rejection is not poorly-configured DNS settings, but rather that ADSL is the criterion on which they're rejecting.
– bignose
Jun 13 '10 at 5:07
"Where have you got the impression that the DNS entries are incorrect?" The fact that you specifically mention A and PTR records, but you ignore rDNS, is a good indication you've messed up there.
– dbc lab
Jun 13 '10 at 15:42
"Where have you got the impression that the DNS entries are incorrect?" The fact that you specifically mention A and PTR records, but you ignore rDNS, is a good indication you've messed up there.
– dbc lab
Jun 13 '10 at 15:42
One of us is very confused. I answered your questions about rDNS. Do you think rDNS uses something other than PTR records?
– bignose
Jun 14 '10 at 7:23
One of us is very confused. I answered your questions about rDNS. Do you think rDNS uses something other than PTR records?
– bignose
Jun 14 '10 at 7:23
|
show 3 more comments
Doing what you propose here will likely eventually result in you no longer receiving email from the biggest and most widely used domains in the world (gmail, hotmail, yahoo, etc.).
I'm also open to other suggestions for
how this problem might be addressed
(short of not using this mail host at
all, which isn't an option).
The first thing I'd try is to make sure the PTR record for your IP matches your domain, and does not resolve to something like "user1235.big-isp-adsl-for-the-masses.com".
But ultimately, and I know this answer sucks, I think the only thing you are going to be able to do to properly send to those domains that currently reject you is to get a new IP address for your mail host. I know, it isn't fair. And I strongly urge you to fight the good fight. But when you get tired of your mail getting lost sporadically, then I think you'll decide that getting a new IP is what you've gotta do (or bite the bullet and move to a different server/host that works).
answered Jul 2 '10 at 1:35
Jed DanielsJed Daniels
5,9792739
Thanks. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end.
– bignose
Jul 2 '10 at 12:26
add a comment |
Doing what you propose here will likely eventually result in you no longer receiving email from the biggest and most widely used domains in the world (gmail, hotmail, yahoo, etc.).
I'm also open to other suggestions for
how this problem might be addressed
(short of not using this mail host at
all, which isn't an option).
The first thing I'd try is to make sure the PTR record for your IP matches your domain, and does not resolve to something like "user1235.big-isp-adsl-for-the-masses.com".
But ultimately, and I know this answer sucks, I think the only thing you are going to be able to do to properly send to those domains that currently reject you is to get a new IP address for your mail host. I know, it isn't fair. And I strongly urge you to fight the good fight. But when you get tired of your mail getting lost sporadically, then I think you'll decide that getting a new IP is what you've gotta do (or bite the bullet and move to a different server/host that works).
answered Jul 2 '10 at 1:35
Jed DanielsJed Daniels
5,9792739
Thanks. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end.
– bignose
Jul 2 '10 at 12:26
add a comment |
Doing what you propose here will likely eventually result in you no longer receiving email from the biggest and most widely used domains in the world (gmail, hotmail, yahoo, etc.).
I'm also open to other suggestions for
how this problem might be addressed
(short of not using this mail host at
all, which isn't an option).
The first thing I'd try is to make sure the PTR record for your IP matches your domain, and does not resolve to something like "user1235.big-isp-adsl-for-the-masses.com".
But ultimately, and I know this answer sucks, I think the only thing you are going to be able to do to properly send to those domains that currently reject you is to get a new IP address for your mail host. I know, it isn't fair. And I strongly urge you to fight the good fight. But when you get tired of your mail getting lost sporadically, then I think you'll decide that getting a new IP is what you've gotta do (or bite the bullet and move to a different server/host that works).
answered Jul 2 '10 at 1:35
Jed DanielsJed Daniels
5,9792739
Doing what you propose here will likely eventually result in you no longer receiving email from the biggest and most widely used domains in the world (gmail, hotmail, yahoo, etc.).
I'm also open to other suggestions for
how this problem might be addressed
(short of not using this mail host at
all, which isn't an option).
The first thing I'd try is to make sure the PTR record for your IP matches your domain, and does not resolve to something like "user1235.big-isp-adsl-for-the-masses.com".
But ultimately, and I know this answer sucks, I think the only thing you are going to be able to do to properly send to those domains that currently reject you is to get a new IP address for your mail host. I know, it isn't fair. And I strongly urge you to fight the good fight. But when you get tired of your mail getting lost sporadically, then I think you'll decide that getting a new IP is what you've gotta do (or bite the bullet and move to a different server/host that works).
answered Jul 2 '10 at 1:35
Jed DanielsJed Daniels
5,9792739
answered Jul 2 '10 at 1:35
Jed DanielsJed Daniels
5,9792739
answered Jul 2 '10 at 1:35
Jed DanielsJed Daniels
5,9792739
answered Jul 2 '10 at 1:35
Jed DanielsJed Daniels
5,9792739
5,9792739
Thanks. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end.
– bignose
Jul 2 '10 at 12:26
add a comment |
Thanks. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end.
– bignose
Jul 2 '10 at 12:26
Thanks. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end.
– bignose
Jul 2 '10 at 12:26
Thanks. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end.
– bignose
Jul 2 '10 at 12:26
add a comment |
i am VERY recommend you to find freshest instruction for antispam or your mail server became spam-botted within 2 days.
and "refusing SMTP sessions that declare a sender domain which itself refuses SMTP" is not enough!
it`s from my own experience :( (but for another mailer)
answered Jun 9 '10 at 4:21
evg345evg345
36614
Thanks, but this doesn't address what I've written. The mail server is existing for a while, and has adequate protection against unsolicited junk. I'm talking about adding a new restriction onto an existing mail server.
– bignose
Jun 9 '10 at 6:13
add a comment |
i am VERY recommend you to find freshest instruction for antispam or your mail server became spam-botted within 2 days.
and "refusing SMTP sessions that declare a sender domain which itself refuses SMTP" is not enough!
it`s from my own experience :( (but for another mailer)
answered Jun 9 '10 at 4:21
evg345evg345
36614
Thanks, but this doesn't address what I've written. The mail server is existing for a while, and has adequate protection against unsolicited junk. I'm talking about adding a new restriction onto an existing mail server.
– bignose
Jun 9 '10 at 6:13
add a comment |
i am VERY recommend you to find freshest instruction for antispam or your mail server became spam-botted within 2 days.
and "refusing SMTP sessions that declare a sender domain which itself refuses SMTP" is not enough!
it`s from my own experience :( (but for another mailer)
answered Jun 9 '10 at 4:21
evg345evg345
36614
i am VERY recommend you to find freshest instruction for antispam or your mail server became spam-botted within 2 days.
and "refusing SMTP sessions that declare a sender domain which itself refuses SMTP" is not enough!
it`s from my own experience :( (but for another mailer)
answered Jun 9 '10 at 4:21
evg345evg345
36614
answered Jun 9 '10 at 4:21
evg345evg345
36614
answered Jun 9 '10 at 4:21
evg345evg345
36614
answered Jun 9 '10 at 4:21
evg345evg345
36614
36614
Thanks, but this doesn't address what I've written. The mail server is existing for a while, and has adequate protection against unsolicited junk. I'm talking about adding a new restriction onto an existing mail server.
– bignose
Jun 9 '10 at 6:13
add a comment |
Thanks, but this doesn't address what I've written. The mail server is existing for a while, and has adequate protection against unsolicited junk. I'm talking about adding a new restriction onto an existing mail server.
– bignose
Jun 9 '10 at 6:13
Thanks, but this doesn't address what I've written. The mail server is existing for a while, and has adequate protection against unsolicited junk. I'm talking about adding a new restriction onto an existing mail server.
– bignose
Jun 9 '10 at 6:13
Thanks, but this doesn't address what I've written. The mail server is existing for a while, and has adequate protection against unsolicited junk. I'm talking about adding a new restriction onto an existing mail server.
– bignose
Jun 9 '10 at 6:13
add a comment |
You could use ppolicy to add new policies. You will probably need to write your own module, but it should be do-able
https://bimbo.fjfi.cvut.cz/ppolicy/browser/trunk/README
answered Jun 9 '10 at 12:21
Pablo MartinezPablo Martinez
1,8661110
add a comment |
You could use ppolicy to add new policies. You will probably need to write your own module, but it should be do-able
https://bimbo.fjfi.cvut.cz/ppolicy/browser/trunk/README
answered Jun 9 '10 at 12:21
Pablo MartinezPablo Martinez
1,8661110
add a comment |
You could use ppolicy to add new policies. You will probably need to write your own module, but it should be do-able
https://bimbo.fjfi.cvut.cz/ppolicy/browser/trunk/README
answered Jun 9 '10 at 12:21
Pablo MartinezPablo Martinez
1,8661110
You could use ppolicy to add new policies. You will probably need to write your own module, but it should be do-able
https://bimbo.fjfi.cvut.cz/ppolicy/browser/trunk/README
answered Jun 9 '10 at 12:21
Pablo MartinezPablo Martinez
1,8661110
answered Jun 9 '10 at 12:21
Pablo MartinezPablo Martinez
1,8661110
answered Jun 9 '10 at 12:21
Pablo MartinezPablo Martinez
1,8661110
answered Jun 9 '10 at 12:21
Pablo MartinezPablo Martinez
1,8661110
1,8661110
add a comment |
add a comment |
Check http://www.spamhaus.org/pbl/ list.
If it is there, and it is a static address, you will be able to remove it.
answered Jun 11 '10 at 8:35
silksilk
823513
That is one of the black lists included in the aggregate checks suggested in JohnnyD's answer. The address is not currently listed at that service.
– bignose
Jun 13 '10 at 2:21
add a comment |
Check http://www.spamhaus.org/pbl/ list.
If it is there, and it is a static address, you will be able to remove it.
answered Jun 11 '10 at 8:35
silksilk
823513
That is one of the black lists included in the aggregate checks suggested in JohnnyD's answer. The address is not currently listed at that service.
– bignose
Jun 13 '10 at 2:21
add a comment |
Check http://www.spamhaus.org/pbl/ list.
If it is there, and it is a static address, you will be able to remove it.
answered Jun 11 '10 at 8:35
silksilk
823513
Check http://www.spamhaus.org/pbl/ list.
If it is there, and it is a static address, you will be able to remove it.
answered Jun 11 '10 at 8:35
silksilk
823513
answered Jun 11 '10 at 8:35
silksilk
823513
answered Jun 11 '10 at 8:35
silksilk
823513
answered Jun 11 '10 at 8:35
silksilk
823513
823513
That is one of the black lists included in the aggregate checks suggested in JohnnyD's answer. The address is not currently listed at that service.
– bignose
Jun 13 '10 at 2:21
add a comment |
That is one of the black lists included in the aggregate checks suggested in JohnnyD's answer. The address is not currently listed at that service.
– bignose
Jun 13 '10 at 2:21
That is one of the black lists included in the aggregate checks suggested in JohnnyD's answer. The address is not currently listed at that service.
– bignose
Jun 13 '10 at 2:21
That is one of the black lists included in the aggregate checks suggested in JohnnyD's answer. The address is not currently listed at that service.
– bignose
Jun 13 '10 at 2:21
add a comment |
Spamhaus and/or greylisting will drop most of the problem addresses. Requiring FQDN in the helo/ehlo messages will catch a lot of the rest.
Dropping messages from servers which don't accept messages won't work if they also do the same. There are a number of legitimate senders who don't accept bounce messages after the fact.
Bounce the message during the connection not afterwards or you will contribute to SPAM through backscatter.
DNS and rDNS need to agree for your server. If your address is listed as dynamic at Spamhaus, you will be refused by a large number of servers, mine included.
answered Jul 2 '10 at 3:32
BillThor BillThor
24.8k22662
Senders don't themselves have to accept mail, but they do need to have an MX record. If the sender's MX host refuses mail, I don't want to accept the incoming connection from the sender in the first place.
– bignose
May 8 '11 at 1:53
@bignose: There are a number of legitmate mailing list and autmated senders who do NOT accept e-mail in any form either at the address or their MX. This is bad form, but gets rid of all the spam they are likely to get. If you don't mind dropping these mail sources, you can drop senders you can't reply to. Howver, callouts to some of the big freemail senders can get your reputation with them downgraded (again bad form).
– BillThor
May 8 '11 at 18:28
“If you don't mind dropping these mail sources, you can drop senders you can't reply to.” Yes, that's exactly what this question is asking. If you know how to do that, please write an answer!
– bignose
May 12 '11 at 3:26
@bignose Exim provides a verify_sender condition for ACLs. I limit it to sroute checking, as checking senders drops legitimate mail my user want. There are options to check for a valid postmaster or random userids. See exim.org/exim-html-current/doc/html/spec_html/… for details.
– BillThor
May 12 '11 at 13:41
add a comment |
Spamhaus and/or greylisting will drop most of the problem addresses. Requiring FQDN in the helo/ehlo messages will catch a lot of the rest.
Dropping messages from servers which don't accept messages won't work if they also do the same. There are a number of legitimate senders who don't accept bounce messages after the fact.
Bounce the message during the connection not afterwards or you will contribute to SPAM through backscatter.
DNS and rDNS need to agree for your server. If your address is listed as dynamic at Spamhaus, you will be refused by a large number of servers, mine included.
answered Jul 2 '10 at 3:32
BillThor BillThor
24.8k22662
Senders don't themselves have to accept mail, but they do need to have an MX record. If the sender's MX host refuses mail, I don't want to accept the incoming connection from the sender in the first place.
– bignose
May 8 '11 at 1:53
@bignose: There are a number of legitmate mailing list and autmated senders who do NOT accept e-mail in any form either at the address or their MX. This is bad form, but gets rid of all the spam they are likely to get. If you don't mind dropping these mail sources, you can drop senders you can't reply to. Howver, callouts to some of the big freemail senders can get your reputation with them downgraded (again bad form).
– BillThor
May 8 '11 at 18:28
“If you don't mind dropping these mail sources, you can drop senders you can't reply to.” Yes, that's exactly what this question is asking. If you know how to do that, please write an answer!
– bignose
May 12 '11 at 3:26
@bignose Exim provides a verify_sender condition for ACLs. I limit it to sroute checking, as checking senders drops legitimate mail my user want. There are options to check for a valid postmaster or random userids. See exim.org/exim-html-current/doc/html/spec_html/… for details.
– BillThor
May 12 '11 at 13:41
add a comment |
Spamhaus and/or greylisting will drop most of the problem addresses. Requiring FQDN in the helo/ehlo messages will catch a lot of the rest.
Dropping messages from servers which don't accept messages won't work if they also do the same. There are a number of legitimate senders who don't accept bounce messages after the fact.
Bounce the message during the connection not afterwards or you will contribute to SPAM through backscatter.
DNS and rDNS need to agree for your server. If your address is listed as dynamic at Spamhaus, you will be refused by a large number of servers, mine included.
answered Jul 2 '10 at 3:32
BillThor BillThor
24.8k22662
Spamhaus and/or greylisting will drop most of the problem addresses. Requiring FQDN in the helo/ehlo messages will catch a lot of the rest.
Dropping messages from servers which don't accept messages won't work if they also do the same. There are a number of legitimate senders who don't accept bounce messages after the fact.
Bounce the message during the connection not afterwards or you will contribute to SPAM through backscatter.
DNS and rDNS need to agree for your server. If your address is listed as dynamic at Spamhaus, you will be refused by a large number of servers, mine included.
answered Jul 2 '10 at 3:32
BillThor BillThor
24.8k22662
answered Jul 2 '10 at 3:32
BillThor BillThor
24.8k22662
answered Jul 2 '10 at 3:32
BillThor BillThor
24.8k22662
answered Jul 2 '10 at 3:32
BillThor BillThor
24.8k22662
24.8k22662
Senders don't themselves have to accept mail, but they do need to have an MX record. If the sender's MX host refuses mail, I don't want to accept the incoming connection from the sender in the first place.
– bignose
May 8 '11 at 1:53
@bignose: There are a number of legitmate mailing list and autmated senders who do NOT accept e-mail in any form either at the address or their MX. This is bad form, but gets rid of all the spam they are likely to get. If you don't mind dropping these mail sources, you can drop senders you can't reply to. Howver, callouts to some of the big freemail senders can get your reputation with them downgraded (again bad form).
– BillThor
May 8 '11 at 18:28
“If you don't mind dropping these mail sources, you can drop senders you can't reply to.” Yes, that's exactly what this question is asking. If you know how to do that, please write an answer!
– bignose
May 12 '11 at 3:26
@bignose Exim provides a verify_sender condition for ACLs. I limit it to sroute checking, as checking senders drops legitimate mail my user want. There are options to check for a valid postmaster or random userids. See exim.org/exim-html-current/doc/html/spec_html/… for details.
– BillThor
May 12 '11 at 13:41
add a comment |
Senders don't themselves have to accept mail, but they do need to have an MX record. If the sender's MX host refuses mail, I don't want to accept the incoming connection from the sender in the first place.
– bignose
May 8 '11 at 1:53
@bignose: There are a number of legitmate mailing list and autmated senders who do NOT accept e-mail in any form either at the address or their MX. This is bad form, but gets rid of all the spam they are likely to get. If you don't mind dropping these mail sources, you can drop senders you can't reply to. Howver, callouts to some of the big freemail senders can get your reputation with them downgraded (again bad form).
– BillThor
May 8 '11 at 18:28
“If you don't mind dropping these mail sources, you can drop senders you can't reply to.” Yes, that's exactly what this question is asking. If you know how to do that, please write an answer!
– bignose
May 12 '11 at 3:26
@bignose Exim provides a verify_sender condition for ACLs. I limit it to sroute checking, as checking senders drops legitimate mail my user want. There are options to check for a valid postmaster or random userids. See exim.org/exim-html-current/doc/html/spec_html/… for details.
– BillThor
May 12 '11 at 13:41
Senders don't themselves have to accept mail, but they do need to have an MX record. If the sender's MX host refuses mail, I don't want to accept the incoming connection from the sender in the first place.
– bignose
May 8 '11 at 1:53
Senders don't themselves have to accept mail, but they do need to have an MX record. If the sender's MX host refuses mail, I don't want to accept the incoming connection from the sender in the first place.
– bignose
May 8 '11 at 1:53
@bignose: There are a number of legitmate mailing list and autmated senders who do NOT accept e-mail in any form either at the address or their MX. This is bad form, but gets rid of all the spam they are likely to get. If you don't mind dropping these mail sources, you can drop senders you can't reply to. Howver, callouts to some of the big freemail senders can get your reputation with them downgraded (again bad form).
– BillThor
May 8 '11 at 18:28
@bignose: There are a number of legitmate mailing list and autmated senders who do NOT accept e-mail in any form either at the address or their MX. This is bad form, but gets rid of all the spam they are likely to get. If you don't mind dropping these mail sources, you can drop senders you can't reply to. Howver, callouts to some of the big freemail senders can get your reputation with them downgraded (again bad form).
– BillThor
May 8 '11 at 18:28
“If you don't mind dropping these mail sources, you can drop senders you can't reply to.” Yes, that's exactly what this question is asking. If you know how to do that, please write an answer!
– bignose
May 12 '11 at 3:26
“If you don't mind dropping these mail sources, you can drop senders you can't reply to.” Yes, that's exactly what this question is asking. If you know how to do that, please write an answer!
– bignose
May 12 '11 at 3:26
@bignose Exim provides a verify_sender condition for ACLs. I limit it to sroute checking, as checking senders drops legitimate mail my user want. There are options to check for a valid postmaster or random userids. See exim.org/exim-html-current/doc/html/spec_html/… for details.
– BillThor
May 12 '11 at 13:41
@bignose Exim provides a verify_sender condition for ACLs. I limit it to sroute checking, as checking senders drops legitimate mail my user want. There are options to check for a valid postmaster or random userids. See exim.org/exim-html-current/doc/html/spec_html/… for details.
– BillThor
May 12 '11 at 13:41
add a comment |
Can you set up your mailserver to pass all outbound mail to an upstream host (at the ISP, or a separate paid service) that's not blacklisted?
Does your customer know you're proposing/working on an approach that's going to result in them not getting inbound E-mail from their customers? I think the "bounce mail from people who discriminate against ADSL SMTP senders" policy is going to cause confusion for your customer (who will get phone calls asking about the bounces) and ultimately make their system(s) less useful, which is hard to justify.
answered Jul 2 '10 at 6:18
gbroilesgbroiles
1,20487
Thanks. Currently, senders succeed in getting a message delivered, but then there's no way to reply back. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end. That will be an improvement over the current situation.
– bignose
Jul 2 '10 at 12:27
add a comment |
Can you set up your mailserver to pass all outbound mail to an upstream host (at the ISP, or a separate paid service) that's not blacklisted?
Does your customer know you're proposing/working on an approach that's going to result in them not getting inbound E-mail from their customers? I think the "bounce mail from people who discriminate against ADSL SMTP senders" policy is going to cause confusion for your customer (who will get phone calls asking about the bounces) and ultimately make their system(s) less useful, which is hard to justify.
answered Jul 2 '10 at 6:18
gbroilesgbroiles
1,20487
Thanks. Currently, senders succeed in getting a message delivered, but then there's no way to reply back. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end. That will be an improvement over the current situation.
– bignose
Jul 2 '10 at 12:27
add a comment |
Can you set up your mailserver to pass all outbound mail to an upstream host (at the ISP, or a separate paid service) that's not blacklisted?
Does your customer know you're proposing/working on an approach that's going to result in them not getting inbound E-mail from their customers? I think the "bounce mail from people who discriminate against ADSL SMTP senders" policy is going to cause confusion for your customer (who will get phone calls asking about the bounces) and ultimately make their system(s) less useful, which is hard to justify.
answered Jul 2 '10 at 6:18
gbroilesgbroiles
1,20487
Can you set up your mailserver to pass all outbound mail to an upstream host (at the ISP, or a separate paid service) that's not blacklisted?
Does your customer know you're proposing/working on an approach that's going to result in them not getting inbound E-mail from their customers? I think the "bounce mail from people who discriminate against ADSL SMTP senders" policy is going to cause confusion for your customer (who will get phone calls asking about the bounces) and ultimately make their system(s) less useful, which is hard to justify.
answered Jul 2 '10 at 6:18
gbroilesgbroiles
1,20487
answered Jul 2 '10 at 6:18
gbroilesgbroiles
1,20487
answered Jul 2 '10 at 6:18
gbroilesgbroiles
1,20487
answered Jul 2 '10 at 6:18
gbroilesgbroiles
1,20487
1,20487
Thanks. Currently, senders succeed in getting a message delivered, but then there's no way to reply back. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end. That will be an improvement over the current situation.
– bignose
Jul 2 '10 at 12:27
add a comment |
Thanks. Currently, senders succeed in getting a message delivered, but then there's no way to reply back. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end. That will be an improvement over the current situation.
– bignose
Jul 2 '10 at 12:27
Thanks. Currently, senders succeed in getting a message delivered, but then there's no way to reply back. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end. That will be an improvement over the current situation.
– bignose
Jul 2 '10 at 12:27
Thanks. Currently, senders succeed in getting a message delivered, but then there's no way to reply back. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end. That will be an improvement over the current situation.
– bignose
Jul 2 '10 at 12:27
add a comment |
It dawned on me. You keep mentioning MX records, but those are not what you're looking for. The DNS feature you want to leverage is the TXT record with the SPF line.
https://en.wikipedia.org/wiki/Sender_Policy_Framework
This allows you to whitelist IPs that are allowed to send mail for that domain. But be careful, you can easily cut yourself off if you fail to whitelist your ISP's SMTP relay or if it changes.
And after knowing the name of what we want, finding articles is easy:
https://www.howtoforge.com/postfix_spf
answered 2 days ago
ZdenekZdenek
1324
Yes, MX records – the incoming domain's advertised way for that domain to receive mail – are what I'm looking for (and I've now clarified this in the question, thank you). SPF addresses an entirely different problem, so this answer doesn't apply.
– bignose
yesterday
add a comment |
It dawned on me. You keep mentioning MX records, but those are not what you're looking for. The DNS feature you want to leverage is the TXT record with the SPF line.
https://en.wikipedia.org/wiki/Sender_Policy_Framework
This allows you to whitelist IPs that are allowed to send mail for that domain. But be careful, you can easily cut yourself off if you fail to whitelist your ISP's SMTP relay or if it changes.
And after knowing the name of what we want, finding articles is easy:
https://www.howtoforge.com/postfix_spf
answered 2 days ago
ZdenekZdenek
1324
Yes, MX records – the incoming domain's advertised way for that domain to receive mail – are what I'm looking for (and I've now clarified this in the question, thank you). SPF addresses an entirely different problem, so this answer doesn't apply.
– bignose
yesterday
add a comment |
It dawned on me. You keep mentioning MX records, but those are not what you're looking for. The DNS feature you want to leverage is the TXT record with the SPF line.
https://en.wikipedia.org/wiki/Sender_Policy_Framework
This allows you to whitelist IPs that are allowed to send mail for that domain. But be careful, you can easily cut yourself off if you fail to whitelist your ISP's SMTP relay or if it changes.
And after knowing the name of what we want, finding articles is easy:
https://www.howtoforge.com/postfix_spf
answered 2 days ago
ZdenekZdenek
1324
It dawned on me. You keep mentioning MX records, but those are not what you're looking for. The DNS feature you want to leverage is the TXT record with the SPF line.
https://en.wikipedia.org/wiki/Sender_Policy_Framework
This allows you to whitelist IPs that are allowed to send mail for that domain. But be careful, you can easily cut yourself off if you fail to whitelist your ISP's SMTP relay or if it changes.
And after knowing the name of what we want, finding articles is easy:
https://www.howtoforge.com/postfix_spf
answered 2 days ago
ZdenekZdenek
1324
answered 2 days ago
ZdenekZdenek
1324
answered 2 days ago
ZdenekZdenek
1324
answered 2 days ago
ZdenekZdenek
1324
1324
Yes, MX records – the incoming domain's advertised way for that domain to receive mail – are what I'm looking for (and I've now clarified this in the question, thank you). SPF addresses an entirely different problem, so this answer doesn't apply.
– bignose
yesterday
add a comment |
Yes, MX records – the incoming domain's advertised way for that domain to receive mail – are what I'm looking for (and I've now clarified this in the question, thank you). SPF addresses an entirely different problem, so this answer doesn't apply.
– bignose
yesterday
Yes, MX records – the incoming domain's advertised way for that domain to receive mail – are what I'm looking for (and I've now clarified this in the question, thank you). SPF addresses an entirely different problem, so this answer doesn't apply.
– bignose
yesterday
Yes, MX records – the incoming domain's advertised way for that domain to receive mail – are what I'm looking for (and I've now clarified this in the question, thank you). SPF addresses an entirely different problem, so this answer doesn't apply.
– bignose
yesterday
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f149495%2fincoming-mail-from-sender-mx-record-wont-accept-replies-how-to-block-the-inco%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Just something to consider - One of our web sites is an on-line store, so it sends a fair number of emails (order confirmations and the like). However, that system will not receive emails. If our customers implemented what you are proposing the whole system would be worthless.
– John Gardeniers
Jun 9 '10 at 3:51
I fail to see how you have come to the conclusion that the "other" mail server is misconfigured because it won't accept email from your server. Many entities use different servers for sending and receiving email. My worry is that your lack of understanding of the nuances of email transport may cause undesired results, like users not receiving emails.
– joeqwerty
Jun 9 '10 at 4:53
So basically, the next time I fat finger my mail server and accidentally break inbound mail, you'll compound the situation by rejecting my outgoing mail too?
– Jed Daniels
Jul 2 '10 at 1:17
While it is totally bogus to reject an entire range of IP addresses based on the fact that they are ADSL, it is equally bogus to reject an entire class of senders who reject you. Two wrongs and all that...
– Jed Daniels
Jul 2 '10 at 1:21