It seems that MailGun is using some sort of verification if the target email exists.
It also seems that it thinks the email does not exist in 90% of the cases. I was getting multiple errors that email does not exist and then after 10th try it acknowledged the email exists… only to throw more errors that email does not exist afterward.
Sometimes I was able to get “email exists” then retry with the same email address after 15 seconds and get “email does not exist” instead.
And because some websites use MailGun verification before letting create account, I can’t use my mailbox and had to use gmail to register for Epic Games so I can grab that sweet free games.
Obviously I would like to keep using my mailbox so I actually have control over everything but we have to somehow figure what MailGun is doing and how to make changes to the MiaB to make it work together.
I use domain-wide alias to catch all emails to my main mailbox so I can use different email addresses for every service (and then block that email address if they leaked it/sold to 3rd parties for spam). But that doesn’t seem to be an issue - trying to register with created user and existing email causes the same error. I set verbose logging in postfix and it shouldn’t matter because it finds recipent anyway due to virtual mailbox check (@domain => recipent@domain).
I spent good few hours debugging and I have no idea where to go from now. The logs are IDENTICAL for MailGun checks that say “account exist” and for checks that say “account does not exist” except time and ids of course. Do you have any idea what to do now?
I suspect that if Mailgun doesn’t work with a properly configured install of MiaB, then Mailgun will go out of business.
As best I can tell, you have to be logged with a Mailgun account to test whatever it is you are doing. Maybe someone with an account can help you, but otherwise please post the details of you problem including log entries, error messages, from Mailgun, etc.
Yes, this sounds like a viable theory. I too would like to know the results of the test and if they are as we are suspecting, would love for the OP to give the appropriate feedback to MailGun. Thanks!
Here are verbose logs from mail.log available for 30 days:
Not getting error, getting verification code on my mail:
Pass Vj5Zwd28qA
Email verification error (invalid email), not getting verification code:
Pass eGFBZdPxij
Domain is replaced to prevent bots. Everything else untouched.
The result is the same no matter if the mailbox exist or if it’s sent to another mailbox via domain-wide alias.
In the logs you can see that MailGun is doing their email verification - if it goes thru, you get connection from epic games and receive email verification code, if it doesn’t go thru, you don’t get the connection from epic games. The logs are nearly identical, except the timestamps and ids/hashes.
I temporarily disabled restrictions in \etc\postfix\main.cf: smtpd_relay_restrictions, smtpd_sender_restrictions, smtpd_recipient_restrictions - but they don’t seem to be related to the issue and the result doesn’t change. I refreshed configs and even restarted postfix service before retrying.
I sent an email to MailGun at the time of posting this thread but didn’t get any reply.
I checked some random emails and it seems they accurately find not existing emails, perhaps too aggressively.
If you get an error “Sorry, the email address you entered does not appear to be valid.” try again every minute or so until you succeed. If you get email verification page, click “change the email address” then register again with the same email and you will probably get the previous error instead.
I’m posting them here because the forum prevented me from posting more than 2 links in a single post.
I don’t think I have. Don’t remember doing anything else other than putting * into graylist filter (making everything allowed so essentially disabling graylisting).
PS. I have no issues with https://email-checker.net/validate and I can see it connects to the server and ask for the address I put in form, not sure if the server sends something back to verify that it indeed exist but the website shows addresses as valid.
I am having a similar problem with initial signup e-mails not coming through until the 2nd or 3rd attempt. For this forum I had to have it send the authentication e-mail 3 times before it came through. The first 2 times it was greylisted for some reason that I can’t discern. When it finally came through all 3 came at the same time.
Earlier this evening I was changing my e-mail on other systems including Blizzard, Steam, CreditKarma, and a few others and all but one of them had to send the verification e-mail multiple times before it came through.
Can this functionality be disabled or changed? I am hesitant to continue migrating to my MIAB server if I’m not reliably getting e-mails from legit sources.
Again, how long did you wait for the email, before you forced it to be resent?
It was greylisted because MiaB uses Greylisting.
It sounds like you have received all emails ‘reliably’. Perhaps not instantaneously though.
MiaB by default incorporates Greylisting as a spam reduction method. Every properly configured email server will retry your email until it is delivered. Spammers usually do not have their email servers configured to retry. For many, Greylisting is a 8-10 minute delay on the first email received from a sending domain that is well worth it. It does take a bit of getting used to the idea of having to wait, but the wait is generally worth it. After a month or two, you will hardly notice as all of your important senders will already have been greylisted.
Thanks for the response.
The e-mails on average have taken 10-20 minutes to arrive. I typically waited 5-10 minutes to have it resent.
The problem with e-mails taking more than 5 minutes to arrive is that all of my financial systems that I changed sent a one time code with a 5 minute timer. A couple of them use e-mail OTP codes with a 5 minute timer as a second factor for sign-in. A delay of 10 minutes means I would never be able to sign into those accounts reliably.
I do now understand the purpose of Greylisting, but the question I have is can I manually add known sender addresses to keep them from getting delayed?
Grey listing takes advantage of a standard in mail servers that scam spam servers cannot meet. In my experience, it reduces spam by ~90%.
After a mail server has passed the first greylist test, it is added to a list of passed senders:
Dec 23 07:22:18 mail postgrey[1117]: action=pass, reason=triplet found, client_name=m225-156.mailgun.net, client_address=159.135.225.156/32, sender=bounce+ca78d4.e05498-username=example.com@mailgun.patreon.com, recipient=username@example.com
Even if your first registration attempt fails due to timeout, your second request should arrive instantly, as was my experience with the Epic forum.
There are occasionally issues with large senders who keep retrying using a different server, but this is reported to happen only occasionally and I’ve never experienced it. Also, Yahoo used to use a form of greylisting and I’ve seen numerous universities using it, so there is a real problem sender-side if their servers can’t get through a greylisting filter.
While it is highly recommended not to make changes to the MiaB default as invariably those changes will be overwritten, it has been discussed on the forum how to both disable greylisting and how to add specific senders and domains to the ‘passed senders’ list.
I think you can use the /etc/postgrey/whitelist_clients.local file and avoid settings being overwritten but I haven’t tried an update of the MIAB server to confirm this as yet.
@openletter three of the senders I had issues with took 3 or 4 attempts to come through. The forum registration type things aren’t that big a deal, but with some sites sending time sensitive one time codes that expire in less than 10 minutes it’s overall proving to be a huge pain.
I’ll see what else I can find about manually whitelisting addresses. I’m not too worried about changes I make getting overwritten as I have multiple spots I save custom config files.
Try sending the offending sites an email to postmaster@example.com to inform them that they have a configuration which prevents users from logging into their site due to greylisting.
The thing is though … after they send you the first email and it takes the time it takes to be greylisted, yes the one time code will be no good. But when you request it again, it will come immediately as there is no need to be greylisted, as the sender has already been greylisted and put on the passed senders list.
So really, this is just a one time inconvenience. Just make sure that you don’t request the code for the second time until after the first one arrives.