I wouldn't normally, but 'twas first hit in Google for SPF generator; according to Microsoft's SPF Record Wizard ( http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/), you don't have an SPF record for alertferret.com They claim you need:- v=spf1 mx mx:mail.wiggly.org -all Kind regards Murray Crane On 30 July 2013 17:46, Andy Smith <andy(a)bitfolk.com> wrote:

On 30/07/13 17:46, Andy Smith wrote: Well, I already started looking at this on gmail a few weeks ago, and yes, I couldn't find anyone, just vague support articles. Looking again now though I see a new thing in their support sections, DMARC, which I had not heard of before. Thanks, I will be rooting around and trying any/every thing I can find from the list and other sources. As a bit of an update it *might* be the case for gmail that after having 4-6 friends unmark messages from the domain as spam other people who have never seen the domain in the inbox are getting delivered directly now...which is nice...I will keep the list up to date if I find anything interesting. Regards, Nigel

Further to on-list discussions another sysadmin friend of mine suggested that the fact that the A record for my MX doesn't match the PTR record might be an issue but I feel it is a red herring. I'm pretty sure multiple PTR records is not allowed (or at least discouraged) anyway, which means I would need to start using the real name of my machine for the MX record instead of the one I am using. This isn't that much of a problem really, just means I don't have a nice 'mail.*' MX entry. Thoughts? n

I may be on to something...examining the raw message in gmail shows the following; Received-SPF: fail (google.com: domain of wiggly(a)wiggly.org does not designate 2001:ba8:1f1:f03f:216:4eff:fe05:ae0f as permitted sender) client-ip=2001:ba8:1f1:f03f:216:4eff:fe05:ae0f; Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of wiggly(a)wiggly.org does not designate 2001:ba8:1f1:f03f:216:4eff:fe05:ae0f as permitted sender) smtp.mail=wiggly(a)wiggly.org I have ignored the whole IPv6 issue until now and I'm not sure what my options are. I'm about to go do some research but I guess it is one of; a) stop responding to IPv6 b) fix DNS and PTR records to have correct IPv6 address *wanders off to read gandi DNS docs* n On 30/07/13 21:13, Robert Gauld wrote:

On 30/07/13 23:50, Martijn Grooten wrote: Yeah, the easiest for me was to tell exim not to use ipv6 for now. First email I tried via mail client got through okay. First email I tried through the automated system that runs behind alertferret.com failed but the message displayed in gmail as to why this message was marked as spam was different, it now says it is spam because it is like other messages that have been marked as spam. So, I deleted all the spam messages and sent another...still being classed as spam. Bugger. I am going to delete all email from the gmail test account I am using and try again tomorrow maybe, just in case...I am worried though that it will now have 'learned' that the domain is poisoned... n

On 30/07/2013 23:50, Martijn Grooten wrote: Better yet: publish an AAAA record for your MX. Then your existing SPF record will be correct *and* you'll be able to receive email over IPV6 as well as send it. -- Phil

Hi Nigel, On Thu, August 1, 2013 11:30 am, Nigel Rantor wrote: For what it's worth, a *new* record should effectively be propogated straight away assuming your DNS is configured correctly (i.e. slaves set to update immediately following changes to the master). Mathew (Keen to see IPv6 usage increase, not decrease!)

Thought I would post a final update regarding all of this and thank everyone for their thoughts, help, pointers, resources and time. In the end there were two problems that appear* to have been causing mail to be flagged as spam. 1) SPF / IPv6 I set up SPF records a while ago, maybe a few months, when I got the alertferret domain and rejigged my exim config to allow me to add email domains to my server by just having config files** added by puppet. I did not realise at the time that my server would attempt to contact other people's servers using IPv6, I thought that IPv6 was only in use within bitfolk's borders. I have not been keeping up with IPv6 rollout/adoption so this is my bad. Since there are no AAAA entries for my machines nor PTR records when my exim server spoke to google's mail servers it failed the SPF test and got canned as spam not ham. Fair enough. Current fix is to stop exim using IPv6, I now need to go and look at my machines IPv6 setup at some point. This would not, I assume, have been a problem if I were using a 3rd party email provider like sendgrid/mandrill. 2) Content The alertferret domain is used by a little service I wrote which sends messages on behalf of the user. The messages were taking advantage of "Reply-To" to ensure that if the recipient just hit "Reply" on their MUA the message would be sent to the user who created the message content, not the "noreply(a)alertferret.com" address used as "From" address on the emails. Removing this stops the google/hotmail systems from canning the messages as spam. This would not have been fixed by using a 3rd party email provider like sendgrid/mandrill. Conclusions I would like to be able to use Reply-To as it was intended, and I think my use is perfectly legitimate, the messages themselves make it clear that the message has been sent on behalf of someone else, and clearly states the person's email address. Unfortunately spammers have messed it up for everyone by making the "Reply-To" header a signal for spam. I may have to add an auto-responder to the "noreply(a)alertferret.com" address to inform the person that they should maybe reply to the email in the message rather than the "From" address. Also, having a 19 year old domain that has always been well-behaved w.r.t email and is whitelisted by a few resources is great but I think I need to get a new throwaway domain to test email things in the future. Thanks, Nigel * since this is still all a bit voodoo and unknowable because I cannot ask G/MS which items actually were responsible for getting flagged as spam ** user and alias lists

Hi, That is relevant at the SMTP level. AIUI, Nigel was talking about what appears in the MX record. Regards, @ndy -- andyjpb(a)ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF

On Fri, 2 Aug 2013, Nigel Rantor wrote: It doesn't matter. Take GMail for example: $> dig +short mx gmail.com 20 alt2.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. 5 gmail-smtp-in.l.google.com. $> dig +short a gmail-smtp-in.l.google.com. 173.194.67.27 $> dig +short -x 173.194.67.27 wi-in-f27.1e100.net. However, what does matter is that if you look up the A record for that latter domain, that you'll get the IP address back: $> dig +short a wi-in-f27.1e100.net. 173.194.67.27 216.239.32.27 I think people tend to confuse this with "PTR should match A". Martijn.

On 02/08/13 11:15, Nigel Rantor wrote: AIUI, This arrangement is fine provided otter.wiggly.org appears in the HELO repsonse at the SMTP level. It's must be: think about how it might work if you had more than one relay. Also, look at the DNS setup for cam.ac.uk: that's a relay that's known to be well run. Regards, @ndy -- andyjpb(a)ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF

On 31/07/13 00:37, Jan Henkins wrote: Yeah, it was easy to do so I did it anyway, now my MX for both domains is otter.wiggly.org so the PTR is correct. n

On 30/07/2013 18:21, Jan Henkins wrote: If you think that's bad, then consider that there are a significantly non-zero number of domains that actually explicitly use +all, which as far as I'm concerned is tantamount to declaring 'all spammers in the world may use my domain freely'. http://spf-all.com/stats.html In my mail setup I normally allow domains that pass SPF to skip greylisting, but I have an explicit check for +all which treats it as neutral and falls through to greylisting. Interestingly, I'm starting to see greylisting become less effective as an anti-spam technique. Traditionally greylisting works by temporarily rejecting mail on the first delivery attempt on the assumption that genuine MTAs conform to the specs and will attempt to resend a short while later, while spambots will simply give up and move on to the next target. A few years ago nearly all of the small amount of spam I got was from hosts which passed SPF (presumably either through compromised systems or through loose SPF settings). Nowadays most of my spam is SPF neutral, which in my mail setup gets greylisted. This means that these spams are getting through greylisting, so there are now some spam networks out there which have clued on to this. -- Phil

Phil Stewart said: That's interesting. I'm not noticing any increase in spam getting through, and the logs still show an awful lot not getting past greylisting. There are some 'genuine' senders who don't either because their mail servers don't resend the mail, but these tend to be the ones who don't accept postmaster@ email either, sigh. Ian

Hi, When I first set up my mail relay I got this "delayed delivery" message when trying to inject mail into Yahoo. The URL for the form appears in the error message (which appears in your logs so it should be almost impossible to miss). I had to fill it in a number of time over the first few months but perseverance seemed to work. ...knocks on wood. Regards, @ndy -- andyjpb(a)ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF

On 23/03/14 02:11, Ian wrote: [snip] Yahoo's spam filters are simply broken. I regularly have to explain to people with Yahoo e-mail accounts how to look in their spam folders, where they usually find not just the missing e-mail from me, but lots of other e-mails which have been mis-categorised and they actually want. Unfortunately, Yahoo's attitude to this is "We're big, so we can't be wrong." I generally advise people to get a proper e-mail address instead. John

On 26/03/14 12:26, Ian wrote: Hmm, that sounds like standard greylisting to me. I do it myself on my server, cuts out at least 60% of the spam I get. -- Regards, Jan Henkins