Spamgourmet rejecting our sender verification

[jmonk]

I have been a user of spamgourmet for many years, but two weeks ago it stopped working for my main email address. After many days of testing and talking to my ISP, I finally got through to someone smart, who told me the problem was this:

This sender is rejecting our sender verification attempts due to timeouts:

Jun 11 10:42:04 mx10 postfix/smtpd[15520]: NOQUEUE: reject: RCPT from gourmet.spamgourmet.com[216.75.35.164]: 450 4.1.7 : Sender address rejected: unverified address: conversation with gourmet.spamgourmet.com[216.75.35.164] timed out while receiving the initial server greeting; from= to= proto=ESMTP helo=

As a result we can't verify the sending MTA actually accepts mail at the purported sender address and the messages are rejected.

And furthermore:

The issue at spamgourmet isn't exactly that they don't verify senders but that connections to their servers take too long and time out prior to our verification attempt. It's possible this wasn't always the case: for instance, if they previously responded more promptly it's possible sender verifications were going through.

We may be able to whitelist this domain but it ultimately depends on the volume of mail receive from them and the potential for abuse. Is the address you need to receive mail from unique or are there multiple spamgourmet addresses?

Now I do not entirely understand this. I don't know if this policy of my ISP makes sense (other email places like gmail seem to receive from spamgourmet without problems). But is it possible for spamgourmet's servers to verify better / not time out / whatever? Would this make sense to do, given that possibly other ISPs may have the same policies, or might in the future?

Or, if this is not possible, what do you suggest I tell my ISP?

Thank you.

[Paranoid2000]

While Josh/SysKoll are the best people to give definitive advice on this, I would suggest the following possibilities:

• I'm a little hazy on what your ISP means by "sender verification" but the log suggests that they are trying to make an SMTP (outgoing email) connection to SG (as described here - as SG has been hit with many rogue SMTP connections from zombie PCs, it tries to filter out ones from "dynamic looking" domains. Your ISP mailserver could fall into this category if it has a domain name of, say, 192-168-1-100.dynamic.myisp.com rather than mail.myisp.com. In this case, your ISP would probably be seeing timeouts from other mailservers as well - SG could whitelist the ISP mailserver but in this case, it would be better for the ISP to adjust the domain name.
• Some other aspect of your ISP's connection is causing it to be rejected by SG - the blank parameters in the logs ("from= to= proto=ESMTP helo=") could be one reason why.
• SG is simply unable to respond to SMTP requests quickly enough for your ISP (perhaps due to other anti-spam measures like greylisting) - did they provide any indication of their timeout settings?

Or, if this is not possible, what do you suggest I tell my ISP?

You may wish to point them to the "Drawbacks" section of Wikipedia: Callback Verification - this method does impose on other parties and could result in the ISP being blacklisted themselves.

[SysKoll]

Here is the problem, if I understand correctly: While spamgourmet is attempting to send email through the ISP's MX gateway, the ISP attempts a connection to spamgourmet in order to verify the address that was in the "From" field, using recipient validation.

Unfortunately, this is useless. Recipiend validation is a security flaw these days because it allows spammers to test combinations of strings and names until they find valid recipients. Remember that they have thousands of zombified Windows machines at their disposal. They can quiuckly sift through billions of combos.

So as a result, we happily "validate" all senders and do our own filtering. Your ISP will always get a validationpositive from us.

However, on top of that, the validation attempt seems to have a very short time-out. And when our machine is saturated, it tends to get slow at accepting incoming connections. When some idiot attempts to flood us (that is, most of the time), time-outs become endemic.

The validation is therefore failing because it times out too fast for us. And even if it succeeded, it would always come back positive, so it would be useless.

Please forward that to your ISP. If it's a US-based ISP, I can even call them if needed. Try to get them into whitelisting us. We are fighting with the good guys, after all.

--SysKoll