Simon Wilson <si...@simonandkate.net>
is rumored to have said:
Question about one of those services that validates email addresses
on the fly when you fill in a form...
There is one (Briteverify) which seems to fail email addresses at
our postfix server for an unknown reason.
Let's start with 2 stipulations:
1. Briteverify has a history as an abusive facilitator of spammers.
They have a history of attempting to verify bogus addresses
harvested from things like ancient Usenet message IDs at DoS rates.
Whether they are still doing that, I cannot say for sure, but they
have been a bad actor in the past.
2. Everything I postulate below are educated guesses.
I put my email in the form (it's used by a local food delivery
service), and in the background I see this on my server:
May 22 17:17:44 emp87 postfix/postscreen[805286]: CONNECT from
[184.72.250.175]:35556 to [192.168.1.230]:25
May 22 17:17:44 emp87 postfix/postscreen[805286]: CONNECT from
[107.20.235.139]:41162 to [192.168.1.230]:25
May 22 17:17:44 emp87 postfix/dnsblog[805300]: addr 184.72.250.175
listed by domain hostkarma.junkemailfilter.com as 127.0.1.1
May 22 17:17:44 emp87 postfix/dnsblog[805318]: addr 107.20.235.139
listed by domain hostkarma.junkemailfilter.com as 127.0.1.1
May 22 17:17:49 emp87 postfix/postscreen[805286]: HANGUP after 5.2
from [184.72.250.175]:35556 in tests before SMTP handshake
May 22 17:17:49 emp87 postfix/postscreen[805286]: DISCONNECT
[184.72.250.175]:35556
Interesting... 184.72.250.175 (smtpout37.briteverify.com) connected
for 5.2 seconds and did nothing. I suspect that they got tired of
waiting for a banner, since that's less than the default banner
delay for postscreen.
May 22 17:17:50 emp87 postfix/postscreen[805286]: PASS NEW
[107.20.235.139]:41162
May 22 17:17:52 emp87 postfix/smtpd[805371]: connect from
smtpout10.briteverify.com[107.20.235.139]
OK, so THAT host waited long enough to get past postscreen.
May 22 17:17:54 emp87 postfix/smtpd[805371]: NOQUEUE: reject: RCPT
from smtpout10.briteverify.com[107.20.235.139]: 550 5.1.1
<ptzmxjwhaby4gptl062gu9q886spsiiymnz155jrf_y9yy_8k76zw5ge4af55...@simonandkate.net>: Recipient address rejected: User unknown in virtual alias table; from=<ad...@origindata.com> to=<ptzmxjwhaby4gptl062gu9q886spsiiymnz155jrf_y9yy_8k76zw5ge4af55...@simonandkate.net> proto=SMTP
helo=<smtpout.briteverify.com>
May 22 17:17:54 emp87 postfix/smtpd[805371]: lost connection after
RCPT from smtpout10.briteverify.com[107.20.235.139]
May 22 17:17:54 emp87 postfix/smtpd[805371]: disconnect from
smtpout10.briteverify.com[107.20.235.139] helo=1 mail=1 rcpt=0/1
commands=2/3
Checking for a random (and exceedingly unlikely) address.
Determining whether your domain has a catchall, i.e. eliminating
services like
Mailinator.
May 22 17:17:54 emp87 postfix/postscreen[805286]: CONNECT from
[50.19.110.184]:41342 to [192.168.1.230]:25
May 22 17:17:54 emp87 postfix/dnsblog[805319]: addr 50.19.110.184
listed by domain hostkarma.junkemailfilter.com as 127.0.1.1
May 22 17:17:58 emp87 postfix/postscreen[805286]: CONNECT from
[184.72.250.175]:35616 to [192.168.1.230]:25
May 22 17:17:58 emp87 postfix/dnsblog[805317]: addr 184.72.250.175
listed by domain hostkarma.junkemailfilter.com as 127.0.1.1
May 22 17:18:00 emp87 postfix/postscreen[805286]: PASS OLD
[50.19.110.184]:41342
Apparently you've seen 50.19.110.184 recently. So postscreen lets it through.
May 22 17:18:01 emp87 postfix/smtpd[805371]: connect from
smtpout29.briteverify.com[50.19.110.184]
May 22 17:18:03 emp87 postfix/postscreen[805286]: HANGUP after 5.2
from [184.72.250.175]:35616 in tests before SMTP handshake
May 22 17:18:03 emp87 postfix/postscreen[805286]: DISCONNECT
[184.72.250.175]:35616
Once again, 184.72.250.175 shows up and stares at you blankly for
5.2 seconds before walking away.
May 22 17:18:03 emp87 policyd-spf[805831]: prepend
Authentication-Results: mail.simonandkate.net; spf=pass (mailfrom)
smtp.mailfrom=origindata.com (client-ip=50.19.110.184;
helo=smtpout.briteverify.com; envelope-from=ad...@origindata.com;
receiver=postmas...@simonandkate.net)
May 22 17:18:03 emp87 postfix/smtpd[805371]: E32D89606:
client=smtpout29.briteverify.com[50.19.110.184]
May 22 17:18:04 emp87 postfix/smtpd[805371]: disconnect from
smtpout29.briteverify.com[50.19.110.184] helo=1 mail=1 rcpt=1
quit=1 commands=4
Meanwhile, 50.19.110.184 makes it through to a successful RCPT
command for postmaster before politely declining to send email.
...and the webpage pops up an error about it being an invalid email
address. I can use my work email address and it validates and I can
order dinner :-D
"Work" email systems tend to avoid (or not even have support for)
anything that intentionally delays mail.
Yes, and given my work email system is not an open relay I can only
assume, per your conclusions here, that the difference is postscreen.
Has anyone else any experience on what exactly they are looking for
to actually validate? They don't actually appear to test for my
email address, rather the non-valid recipient address which is
rejected, then postmaster which passes early tests but is
disconnected by the client before being fully sent.
My guess is that the 5.2-second null connections are significant. I
suspect that you can fix this without significantly damaging the
effect of the postscreen PREGREET test by reducing the wait time to
never exceed that 5.2 seconds, e.g.:
postconf -e 'postscreen_greet_wait = ${stress?{2}:{4}}s'
That will probably reduce your overall PREGREET rejections by <1%
but IF that is the cause of the null sessions from Briteverify, it
should fix them.
OR: You could complain to the food delivery company that their
disreputable mail verification provider is rejecting valid addresses
and they should save their money by just doing normal verification
with a human component (i.e. email you a code to enter into the form.)
Bill, thank you for taking the time to write such a comprehensive
response. I've pulled back the postscreen delay per your suggestion
and will test that.
I did try and reach out to briteverify a few weeks ago to no response,
and I suspect it would be a complete waste of time (unfortunately)
contacting the food company.
Some choose to block them completely and that is their choice - if I
can tweak slightly so my users can maximise usage without impacts I'd
rather do that.
Simon.
--
Simon Wilson
M: 0400 12 11 16
