Various email issues, including domains without MX records
Hi all I've been paying attention to our mail logs lately and seeing some "interesting" stuff. So I was wondering... Does anyone run a serious (commercial) email operation in New Zealand without having appropriate MX records these days? (i.e. relying on the legacy behaviour of using A records in the absence of MX records.) What about web forms? What about embedded devices? What proportion of valid mail in NZ is sent from an address that doesn't have an MX record? Do you check? What do you do if it's not? If one were to block email from addresses without MX records, how much would break? How many complaints would one get? -Martin -- Martin D Kealey, ihüg engineering
On 10/07/07, Martin Kealey wrote:
If one were to block email from addresses without MX records, how much would break? How many complaints would one get?
Try it for a while. Setting up an MX record is not difficult. Anyone who can't handle that shouldn't be running a mail server. Maybe if ISPs starting block mail from domains that don't have one, those mail admins will get one. Yuri
On Tue, 10 Jul 2007, Martin Kealey wrote:
What proportion of valid mail in NZ is sent from an address that doesn't have an MX record? Do you check? What do you do if it's not? If one were to block email from addresses without MX records, how much would break? How many complaints would one get?
You'd break a bit. Lots of automated emails come from addresses like "root(a)machine.domain.co.nz" which won't have a MX record or possible any (remotely viewable) DNS at all. Unless you are going to block a huge amount of spam by doing it then it is probably not a good idea. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
On 10/07/2007, at 7:42 PM, Simon Lyall wrote:
On Tue, 10 Jul 2007, Martin Kealey wrote:
What proportion of valid mail in NZ is sent from an address that doesn't have an MX record? Do you check? What do you do if it's not? If one were to block email from addresses without MX records, how much would break? How many complaints would one get?
You'd break a bit. Lots of automated emails come from addresses like "root(a)machine.domain.co.nz" which won't have a MX record or possible any (remotely viewable) DNS at all.
Unless you are going to block a huge amount of spam by doing it then it is probably not a good idea.
Yes, from what I can tell, iHug started doing this recently. Wait, no, they are checking that my mail server would accept messages for the envelope sender address. Because mail from a bunch of users' PHP code has an envelope sender of apache(a)hostname (but a valid "From:" header in each email), I have to accept mail for apache(a)hostname (or at least pretend I do). it's not really a /huge/ problem, but it's annoying to have to do so. Infact, I haven't bothered yet. -- Nathan Ward
Unless you are going to block a huge amount of spam by doing it then it is probably not a good idea.
Yes, from what I can tell, iHug started doing this recently. Wait, no, they are checking that my mail server would accept messages for the envelope sender address. Because mail from a bunch of users' PHP code has an envelope sender of apache(a)hostname (but a valid "From:" header in each email), I have to accept mail for apache(a)hostname (or at least pretend I do). it's not really a /huge/ problem, but it's annoying to have to do so. Infact, I haven't bothered yet.
Another thumbs down for Ihug. I am dealing with rejections from Ihug because the envelope-sender address that my PHP driven systems use, is web-server-owner(a)mx.host. IF it were simply @domain, it'd work fine, but the MX record for my domain does not in itself have an MX record, and is not actually configured for mail... So far, its only Ihug that has a problem, and only recently - but what bothers me is that it ignores the 'From:' and rejects based on an inability to validate the envelope-sender. I havn't taken any active steps to 'fix' it yet, as i'm yet to see why its 'broken'. Apparently Orcon employ something similar, but I havn't had any bounces from them yet... (maybe its just a matter of time...) Mark.
Yes, from what I can tell, iHug started doing this recently. Wait, no, they are checking that my mail server would accept messages for the envelope sender address. Because mail from a bunch of users' PHP code has an envelope sender of apache(a)hostname (but a valid "From:" header in each email), I have to accept mail for apache(a)hostname (or at least pretend I do). it's not really a /huge/ problem, but it's annoying to have to do so. Infact, I haven't bothered yet.
Yes callbacks..They are very helpfull and there are people on both sides which give good/bad reasons for them, but they definately do reduce the amount of spam coming in a lot, but you have to be carefull in whitelisting a few of them common problems like machines sending from www-data@ apache@ etc (there are quite a lot). IMHO if "something" sends out email. then there must be the possibility to "bounce" something back to it for whatever reason and sending the original message from an invalid (an email address which doesn't exist) MFROM doesn't help at all. Thanks Craig .
Craig Whitmore wrote:
Yes callbacks..They are very helpfull and there are people on both sides which give good/bad reasons for them, but they definately do reduce the amount of spam coming in a lot, but you have to be carefull in whitelisting a few of them common problems like machines sending from www-data@ apache@ etc (there are quite a lot).
IMHO if "something" sends out email. then there must be the possibility to "bounce" something back to it for whatever reason and sending the original message from an invalid (an email address which doesn't exist) MFROM doesn't help at all.
Callbacks can provide value, but can also be a royal pain-in-the-ass as well. The wikipedia page[1] has some comments on the pros/cons; but I have seen machines die from callback initiated DDoS/DoS. Not pretty... but I guess you take the risk with any anti-spam mechanism. [1] http://en.wikipedia.org/wiki/Callback_verification aj.
"Message rejected by filter rule match" from previous email so lets try the URL's again with spaces in them.. Exim will for example not allow email to come in when the MX is invalid (an A record is treated as the MX if the MX is missing.) For example look at the MX's for these. a b so l u t e c a s h.n e t p o s t m a n p a t.o r g.u k j o i n t h e f u t u r e.c o m p a y b y e s c r o w.c o m p h a y z e.c o m Thanks
On Tue, Jul 10, 2007 at 05:56:53PM +1200, Martin Kealey wrote:
Does anyone run a serious (commercial) email operation in New Zealand without having appropriate MX records these days? (i.e. relying on the legacy behaviour of using A records in the absence of MX records.)
Why not test it out? Grab your mail logs and write a script to do the MX lookup - you'll quickly get a feel for how many you'd block. iiNet in Australia recently started enforcing that all hosts sending them email must have a PTR record setup (ie, reverse DNS). Certainly caused a number of complaints, but they are still doing it so I presume that they are seeing some benefits from doing so. Scott.
Martin Kealey wrote:
Hi all
I've been paying attention to our mail logs lately and seeing some "interesting" stuff. So I was wondering...
Does anyone run a serious (commercial) email operation in New Zealand without having appropriate MX records these days? (i.e. relying on the legacy behaviour of using A records in the absence of MX records.) What about web forms? What about embedded devices?
What proportion of valid mail in NZ is sent from an address that doesn't have an MX record? Do you check? What do you do if it's not? If one were to block email from addresses without MX records, how much would break? How many complaints would one get?
So in the spirit of Geoff Houston's bgp-the-movie, and xkcd's map of the internet (http://xkcd.com/c195.html) I decided to do some of my own maps of the Internet (don't worry, relevance is arriving soon). http://blag.xkcd.com/2006/12/11/the-map-of-the-internet/ describes the algorithm. I work down to the /20, so the image doesn't get absolutely insanely huge. First I did a map of all the AS's on the Internet, colouring each AS by it's number: http://coders.meta.net.nz/~perry/dump/asmap.png Then I did one of the age of each AS based on it's whois last modified. Brighter red is newer AS's, darker red is older AS's. I guess I should have done this on the last modified of the prefix object but meh, I did AS because of Geoff's cool movie. http://coders.meta.net.nz/~perry/dump/agemap.png But to bring this back on topic, I did a map of where all the spam and ham comes from. Red intensity is the amount of spam, Blue intensity is the amount of ham. http://coders.meta.net.nz/~perry/dump/spammap.png A few conclusions I jumped to when I saw this picture was: * There are only a "few" networks that send mail. Comparing to "agemap" and "asmap" you can see that there is a lot of address space that doesn't send any email. (or at least doesn't send mail anywhere where I can see it) * People that send ham are generally stuck in the middle of people sending spam, although some of these might be false negatives. * Some networks are /really/ bad. * There are extremely few hammy sites, less than 1,000. It would almost be manageable to keep a whitelist up to date by hand. (well, if you were employed full time to do it anyway) There are certainly a lot more spammy hosts than hammy hosts, so RBL's seem to be fighting the wrong end of the war. * Sites send ham or spam (red or blue), sites don't send ham and spam (purple). * Theres very little spam in the "lower right" of the map which I think is the old Class C space (192/3). * I need more data to really flesh this out. Feel free to jump to any other conclusions you feel like from this data :)
participants (9)
-
Alastair Johnson -
Craig Whitmore -
Mark Foster -
Martin Kealey -
Nathan Ward -
Perry Lorier -
Scott Howard -
Simon Lyall -
yuri