Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Hotmail vs. SPF vs. behind-the-times ISP 1

Status
Not open for further replies.

OsakaWebbie

Programmer
Feb 11, 2003
628
0
0
JP
Recently I have had messages I can't send to hotmail recipients, and it brought the whole SPF issue to my attention. So now I'm trying to come up with an SPF record that will work for my hosted domain. The ISP I connect through has lots of SMTP servers (I can't predict which one will be used at any given time) but no SPF record of their own. If they had an SPF record, I would just use "include:eonet.ne.jp". But how can I make my SPF record work without trying to mention all the ISP's servers (which I, of course, have no list of)?

I originally thought I could just list the sending server name I specify in my email client, but that doesn't work - test emails to a gmail account result in header information telling me that a different server (one of a numbered series) actually did the sending in the end. So it seems that I have to catch all of the ISP's servers somehow. Any ideas?
 
Are you sure that the 'include' option requires the ISP to have their own spf record? Did you try using the wizard for setting up the spf record?
 
Not only that, but I'm not aware of anyone forcefully using SPF. I know a lot of orgs check it, but I don't know any that act on it other than maybe setting some header info.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.
 
Are you sure that the 'include' option requires the ISP to have their own spf record?
Syntax-wise it probably doesn't require it, but I don't know any other way that its various SMTP servers will get associated with a common point that I can reference.

Here's what I know how to look up (and yes, I use the wizard, among a variety of other tools). The main eonet.ne.jp domain has no A records and only one MX record, mx1.eonet.ne.jp, whose DNS contains no leads to anything else. The entry I use for the sending server in my email software account setup is smtpauth.eonet.ne.jp, but that's just an alias for aa0000-msas01s.eonet.ne.jp, which also has no leads anywhere else (and whose naming convention would hint of lots more servers). But when I sent a test message to a gmail account (which puts SPF info in the header), it said that the server that sent the message was actually 203.140.81.50, which is smtp-out03.eonet.ne.jp, yet another name that hints of more where that came from but contains no leads. I see no central point(s) that I can reference that will find the rest of those servers. That's why it seems that unless EONet adds an SPF record (or a network of them - Yahoo Japan has one that includes another, which includes a few more, which include a few more... looks like a pyramid scheme!) I can't figure out how to make an SPF record that will actually work.

Ah, while I was writing this, 58sniper wrote also. I can't be sure that a working SPF will solve it, but the other day when I sent a normal handwritten message to seven recipients (surely that few isn't considered bulk!) including a hotmail address, it was rejected with the following message:
host mx4.hotmail.com[65.54.244.232] said: 550 OU-002 Mail rejected by Windows Live Hotmail for policy reasons. Reasons for rejection may be related to content with spam-like characteristics or IP/domain reputation problems. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit for email delivery information and support (in reply to MAIL FROM command)
I then sent the same message to only the hotmail address, and it was accepted. I read their rules, and including six other recipients is not a violation per se, nor was anything else in my message. My best guess is that they don't reject a message outright just because there is no SPF, but that they consider it worthy of more scrutiny, sort of like having an SPF with "~all" but sending from a server not covered.

I did a little more testing just now (bothering a friend of mine who has hotmail by sending him test messages!), and strangely enough, today even with the same number of addresses as the other day (although different ones - this time I used six of my own addresses), the message gets delivered (I'm not getting any bounces, anyway). The status of my SPF is currently still such that it soft-fails (~all and not naming the sending server correctly). So I actually haven't yet cracked the code of what hotmail does or doesn't like. But I still suspect that if I had a nice solid SPF it would grease the skids.
 
You could try using a your ISP's subnet so your SPF record would look something like v=spf1 ip4:10.10.0.0/16 ~all
 
Thanks, that's helpful, especially since I was trying to spell out even a couple that I knew but seemed to run into a max length error on my hoster's server or something if the string got too long.

I used nslookup over and over to find the outer boundaries of the consecutive block of SMTP servers that I know of (eight addresses), but is there any way to find out, without directly asking the ISP, whether there are other blocks of IPs they use for SMTP?

And I'm a little rusty on subnet syntax - am I right in thinking that to define a last-number range of 44-51 I can't say 203.140.81.44/8 because of where the numbers fall, but instead need to do it in two parts, ...44/4 and ...48/4?
 
Oops, I'm proving how rusty I am - I meant 30, not 4 after the slash! [blush] (I was thinking about how many numbers fall in the range, not how many binary digits are fixed)
 
Just looked up the eonet.ne.jp SPF record and it is
v=spf1 ip4:203.140.81.0/24 ~all

I'd go for adding this as your SPF record as it will give you 256 hosts in this subnet.
 
Of course, that means that anyone could send out email through the ISP's SMTP servers as you and it would be valid according to the SPF record.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.
 
That's a bizarre coincidence of timing. As recently as a few days ago, eonet.ne.jp didn't have an SPF record at all - that's why I started this thread. But while I was trying to figure out what to do, apparently they decided to get on board with the SPF program! [thumbsup]

58sniper, naturally if a spammer gets an account with the same ISP as me, he can send spam in "my name" - but I'm not going to lie awake at night worrying about spammers moving to my city in Japan and signing up for my ISP just to use my domain as a sending address... ;-) Actually, a much more likely scenario is a spammer getting a throwaway domain with the same hoster as me and using the hoster's SMTP servers, which of course are also permitted in my SPF (if they really want to go through all that research to coordinate hosters with harvested email addresses). And of course spammers can still send mail to me using their own throwaway addresses - the SPF system doesn't do anything to address that. But without revamping the entire email protocol, I can't imagine much more that can be done - I think SPF is a pretty good idea for reducing some of the spam.

Thanks, guys (or gals)!
 
Sorry - I meant the hoster's SMTP server.

SPF adoption hasn't been what people thought, as spammers have found ways around it, and to their advantage.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.
 
Yup, it will be a continual battle - each side will respond to the other's tactics. But I don't know about you, but I have noticed a decrease in the amount of spam that reaches my inbox in the last few weeks. I don't know what to credit with the improvement - spam filters at various points in the chain, finding and arresting actual spammers, protocol changes like SPF, or what - but it's a welcome change even if only temporary. It boggles my mind that there are still enough people out there believing the lies (ordering shady pharmaceutical products, falling for phishing schemes, or whatever) to make it worth the spammers' effort, but...

Getting back to the original topic, I have one more question. I thought that rather than imitate my ISP's ip4 definition, it might be safest long term to just "include:" their record, so that if someday they change their configuration it would automatically be reflected in my record. But their record has "?all" at the end, which is pretty lax. At some point I will want to change my record's "~all" to "-all", but will unrelated IPs get permitted based on the ISP's "?all" if I use "include:"? Or is the "all" setting of included SPFs ignored and only the actual host definitions used in the include? Does anyone know?
 
The problem with SPF is no one is really forcing it. Some places check them, but until they become required, we won't see adoption increasing very much.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.
 
Yeah, it's moving slow. I hadn't even heard of it until I started getting bounces from hotmail saying that I was violating policies somehow (their content evaluator thought my message was spamish, I guess, although I have no idea why - it didn't even have any hyperlinks in it), and the bounce message gave a link to their policies site, which recommended SPF. I decided that if I add SPF records it might improve my "reputation" with hotmail and the chances that similar messages will go through in the future.

But now that I have learned about SPF, I'm in favor of it in general, and will do my part to SPF-ize my small corner of the email world, both to help validate my legitimate email and to reduce source-spoofing spam at least to receiving servers that are checking SPF. Once I'm sure I've got the right servers covered in my records, I'll even go to "-all" mode, giving permission for the receiving servers to dump messages that don't match. No, not everybody is checking it, but some are, and every little bit helps.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top