Re: [mailop] fastmail and sender score snafu
> I see that current setup might be useful in case some user changes MX > before the domain is activated at Fastmail, in which case giving 4xx > could make sense. But it is not right to report such re-tries to sender > score as attempts to deliver to non-existing users. Yes, this is why we 4xx rather than 5xx email sent to an unconfigured domain. Many inexperienced email users aren't sure exactly what order to change or set things up in and we've seen users lose email before because they changed the MX records before adding their domain at Fastmail. The 4xx response reduces the chance of lost email. In general it doesn't really matter that it's 4xx not 5xx. There's no sensible reason to point MX records for a domain to us if you're not planning on actually using us for your email. If that does happen, the email will eventually bounce when the other side gives up trying to resend, which in most cases is at most 24 hours. Now clearly there's an interesting and unexpected edge case that's happened here. The logging of repeated delivery to a "non-existent" address has been rolled up into a sender score feed that's affected your servers IP reputation, which is really annoying. Unfortunately fixing the code on this is non-trivial right now since in the policy daemon where this logging occurs we don't actually have the information we need to suppress this case there and then. I have some longer term ideas for this, and will keep this scenario in mind when I get to them. Sorry Kirill, I don't have a really good answer right now, though I would say that "emails would be kept in the queue for a month" is probably actively working against you here. There's no reason an email should be queued for that long. 24 hours seems a high upper bound these days and is the postfix default. It's better that it actually bounce sooner to let the sender know that something went wrong rather than trying for a month and the user not knowing that their email is in limbo somewhere. -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Anyone from chello.nl here?
We're seeing a strange rejection message with emails containing a particular link. Can someone please contact me off list. Thanks -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error
> I'm thinking that perhaps your cert is using SHA-(256|512) and > something better than 3DES for HMAC, and therefore the remote servers > are unable to work with the certificate as they don't have access to > the required crypto. I sincerely hope this is not the case, but > perhaps you can test this by using a certificate signed with "export > grade" algorithms... That's not a bad theory. However I just checked, and our cert was upgraded to sha256 around Dec 2014, but based on our logs, we only had to introduce the workarounds in Oct 2015, so it doesn't seem related to the sha1 -> sha256 upgrade of our cert. Also from what I hear from some others, they don't have problems with a sha256 cert either from the same hosts we're having problems with. Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error
> We've suddenly had a couple of reports from users about people sending > to them (e.g. sending from a remote service to our servers) failing and > bouncing with the error message: > > Certificate rejected over TLS. (unknown protocol) Just to update with more information. So it turns out we'd actually encountered this problem before (Oct 2015), and had put a work around in place at the time. It appears that us.af.mil servers were having problems connecting to our postfix instances and at the time couldn't work out what the obvious reason was so I had added this to our postfix config. main.cf ... # Disable starttls for some problematic hosts smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/access_client-helo_keyword.cidr access_client-helo_keyword.cidr # us.af.mil has TLS problems. IPs taken from SPF record (e.g. dig us.af.mil TXT) 132.3.0.0/16 starttls ... 131.15.70.0/24 starttls It appears recently they must have added additional servers, since their SPF records have changed. Adding these: +131.9.253.0/24 starttls +131.27.1.0/24 starttls Fixed the problem. Ideally I'd like to actually work out what's causing the sending servers to fail with our TLS configuration, but it's a bit of work I haven't had time for, thus this work around for now. -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error
We've suddenly had a couple of reports from users about people sending to them (e.g. sending from a remote service to our servers) failing and bouncing with the error message: Certificate rejected over TLS. (unknown protocol) There's not much more in the error message, I haven't managed to get hold of a complete bounce email yet, or find out what server is being used, but I'm trying to get hold of that information. I don't believe anything has changed on our side (software wise or configuration wise), so I'm not sure why we're suddenly seeing a couple of reports of these errors. We're using postfix 2.11. We've got a valid cert that's not expired. $ echo | openssl s_client -starttls smtp -connect mx1.messagingengine.com:25 2>/dev/null | openssl x509 -noout -dates notBefore=Nov 28 00:00:00 2016 GMT notAfter=Feb 3 12:00:00 2020 GMT Also confirmed it's the same for all of our mx servers. Has anyone seen this error before and/or know what causes it? -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Forwarding problem to cox.net, need a contact
Hi Is there anyone from cox.net on this list? Can you please contact me off list, we're having a problem with email forward to @cox.net accounts. Thanks -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports
> Laura Atkins has some pretty cool ideas here: > https://wordtothewise.com/2014/05/dkim-injected-headers/ > I'd be interested to see if including those headers twice in the > signature works, so an altered or second instance of them would > fail DKIM. They didn't alter any of the headers or add any extra headers. There's no need for the To header to match the SMTP RCPT TO envelope in any way. > And have you had success including the t= and/or an aggressive x= > (expire time) for free accounts? If you look at the Received headers I posted: Thu, 11 Aug 2016 09:25:57 -0400 ... Thu, 11 Aug 2016 06:16:00 -0700 (PDT) So it took about 10 minutes from Receiving the email at gmail until the were sending it from AWS. Having an expiry time that's < 10 minutes in the future from when a message is sent is pretty dangerous. All it takes is a small problem on the receiving side for an email to be delayed 10 minutes. Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports
> 1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in > time. Assuming the receiving side looks at it. But you probably mean the x= tag anyway to set the expiry time, the RFC explicitly says though: INFORMATIVE NOTE: The "x=" tag is not intended as an anti- replay defense. Anyway, if you look at the Received headers I posted: Thu, 11 Aug 2016 09:25:57 -0400 ... Thu, 11 Aug 2016 06:16:00 -0700 (PDT) So it took about 10 minutes from Receiving the email at gmail until the were sending it from AWS. Having an expiry time that's < 10 minutes in the future from when a message is sent is pretty dangerous. All it takes is a small problem on the receiving side for an email to be delayed 10 minutes. > 2. Use per-user selectors with different keys (as it was advised) and > remove DKIM records if replay attack is detected or simply switch > to new selector if per-user keys are impossible. As I previously noted... the timeline between signup a new account, send one email, copy it and mass send via AWS instance could all be done in minutes, and then thrown away. By the time you revoke the selector, 1000's of emails have already been delivered. Sure it'll stop future reusing that particular account, but they can easily just move on to a new account already. > 3. Do not DKIM-sign messages and/or use different domains for trial > accounts. If you have antispam with score, you can set some limits > to sign / not sign messages with DKIM based on the score. At the moment it's trial accounts, but we also see plenty of accounts with stolen credit cards, or long term accounts that are stolen as well (probably due to password reuse). Determining which accounts to feed into a separate domain is non-trivial. It's also easy for the spammer to test. Signup trial account, send to gmail. No DKIM signature or wrong domain? Use a credit card to pay. Still not working? Buy a stolen account on some black market. Still not working due to message content? just tweak their message content and keep trying until they get the DKIM signature they want. Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports
> Use a different selector for each account holder, and then revoke > selectors that are abused. That's an interesting idea, but I'm not sure it'll be a big help. The reality is that the timeline between signup a new account, send one email, copy it and mass send via AWS instance could all be done in minutes, and then thrown away. By the time you revoke the selector, 1000's of emails have already been delivered. Sure it'll stop future reusing that particular account, but they can easily just move on to a new account already... -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports
Hi mailop So it appears at the moment that we're experiencing a DKIM replay attack against us. Basically some people are signing up a trial FastMail account, sending a couple of emails to a gmail account (to get them DKIM signed by us), and then copying the entire content of the email and sending it from an AWS instance. Because Yahoo uses the DKIM signing domain for it's feedback loop reporting, we're receiving 100's -> 1000's of reports, even though none of them were actually sent from our servers. Here's what the cut in the Received headers looks like: Received: from towersevent.net (ec2-52-2-96-133.compute-1.amazonaws.com [52.2.96.133]) by alph136.prodigy.net (8.14.4 IN nd2 TLS/8.14.4) with ESMTP id u7BDOa9x029274 for <...@att.net>; Thu, 11 Aug 2016 09:25:57 -0400 Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com. ) by mx.google.com with ESMTPS id y13si203649qkb.155.2016.08.11.06.16.00 for <...@gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 06:16:00 -0700 (PDT) The bottom Received header shows the jump from us to gmail, but the top Received header shows that basically they just copied the entire email content, and sent it from an AWS instance to a @att.net account. Obviously we're concerned about this because: 1. We only learned about this because yahoo uses DKIM domains for FBL reporting. If they used IP's, we'd never have known about this 2. I bet a number of services out there are using the domains in DKIM signed emails for reputation tracking. So this may be affecting the reputation of our domains, even though we're not the genuine source of the majority of the emails. Does anyone know if (2) is actually true, or what sites might be doing to avoid this? I guess checking the uniqueness of b= value in each DKIM signature to see if it's truly the same email just replayed over and over is one way? That's an interesting thought actually, I wonder if seeing many emails with the same b= value is an easy way to actually detect spam and/or a replay attack? I can't see an easy way to stop this. It's impossible to block every single sent spam email ever, and all it takes is one email sent and signed by us to be able to be replicated as much as anyone wants. I know that this is a known problem with DKIM, just wondering if anyone else has seen this and or dealt with it and has any idea if we should even be worried about it at all? -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] signup form abuse
> I wonder what the point is. How does the bad guy monetize it, or is it a > coordinated attack against a specific victim? What other nefarious > issues? Making the address useless or burying some other mail in the > midst of the junk would seem to be a possibility. > > If an attack against a specific victim, it would seem that unconfirmed > marketing lists would be a more effective weapon than a bunch of random > confirmation messages. We saw this happen a while back: https://blog.fastmail.com/2014/04/10/when-two-factor-authentication-is-not-enough/ About a month ago, our hostmas...@fastmail.fm account suddenly wound up subscribed to hundreds of mailing lists. All these mailing lists failed to use double or confirmed opt-in, so someone was simply able to enter the email address into a form and sign us up, no confirmation required. This really is poor practice, but it's still pretty common out there. A special shout-out goes to government and emergency response agencies in the USA for their non-confirmation signup on mailing lists. Thanks guys. The upshot was that the hostmaster address was receiving significant noise. Rob Mueller (one of our directors) wasted (so we thought) a bunch of his time removing us from those lists one by one, being very careful to check that none of the 'opt-out' links were actually phishing attempts. This turns out to have been time very well spent. -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] outlook.com bouncing emails with ISO-8859-10 charsets?
> just as an fyi, Gmail switched to sending out utf-8 (for messages we > compose) by default in 2014 and removed the feature that allowed users > to override this a year ago. Downgrading from utf-8 to some charset > that handles a much smaller subset of characters seems mostly > unnecessary at this point. We still have some stragglers for other > Google services, but we're working through them. Interesting. We were just debating whether to try this internally the other day. Vague previous memories suggested some Japanese users that needed shift_jis support I thought it was, but that was probably years ago... anyway, I think we'll give it a go, see what washes out. Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] outlook.com bouncing emails with ISO-8859-10 charsets?
Reported by one of our users... --- Diagnostic information for administrators: Generating server: AM4PR0601MB1986.eurprd06.prod.outlook.com ville.kiiv...@ort.fi Remote Server returned '550 5.6.0 CAT.InvalidContent.Exception: InvalidCharsetException, Character set name (ISO-8859-10) is invalid or not installed.; cannot handle content of message with InternalId 5093831213990, InternetMessageId <...>.' --- Really? -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
>> Ok, just to confirm, does this mean you don't recommend or recognise >> SRS rewritten MAIL FROM addresses as special in any way? > > Does anyone understand SRS? I thought it was pretty much a dead end. IMHO everything about SPF and SRS borders on somewhere between pointless and craziness. Is there any evidence it's been useful in any way to help stop or identify spam? > Which reminds me, I need to ping the spam folks again, that page is > still recommending putting SPAM in the subject, which breaks dkim, > which is the last thing you should do. I think we're going to support > an X-Spam header instead... except of course that's a violation of RFC > 6648. Anyone want to recommend a generic header name? Maybe go with something that's already commonly added? https://wiki.apache.org/spamassassin/X_Spam_Status At least the Yes/No bit on the front? > In general, it seems we're way past the point where we should have a > more explicit system for forwarding. Agree. Who wants to write one? :) Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Apple, iPhone setup, attempts SSL on port 587
A client with a new iPhone (not sure what model), attempts to setup imap/smtp using starttls. As part of the setup, the iPhone apparently probes the smtp server on port 587 with an SSL handshake: Jul 29 21:31:34 ns1 sendmail[20641]: t6U4VYQL020641: rejecting commands from 97-93-80-251.static.rvsd.ca.charter.com [97.93.80.251] due to pre- greeting traffic after 0 seconds Having dealt with lots of iOS users for many years, I find this really surprising. I've never seen an iOS device do this before. It does appear to be SSL/TLS traffic, but I'm really surprised it was sent to port 587. Are you absolutely sure this is happening on port 587? Is there anything else logged before or after this from the same IP (maybe get a tcpdump)? Does it actually attempt plaintext + STARTTLS upgrade after the direct TLS/SSL connection fails? -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
[mailop] Anyone from mailchimp here?
Is anyone from mailchimp on this list? I've got some examples of issues with your sending IPs that I'd like to discuss. Please contact me off list. Thanks -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
