[SLL] Greylisting downsides: Solutions?
johnbaxterlists at mac.com
johnbaxterlists at mac.com
Tue Jun 12 14:49:32 PDT 2007
On Jun 12, 2007, at 11:38 AM, Glenn Stone wrote:
> So I was just doing something on a major car-rental company's
> website, and I
> said to myself, "That's gonna generate an email." So I went into
> Postgrey's
> whitelist, added what I *thought* should be the appropriate domain,
> reloaded, hit SUBMIT, and.... nothing. Checked /var/log/mail.log,
> there's
> the attempt, but it HELOed as... who?? Turns out it was a host
> owned by
> Postini, who is apparently handling Not Exactly's email for them.
> (Hertz,
> for what it's worth, whoever is running their email servers
> actually have
> them HELO'ing as hertz.com. Win!)
The HELO (usually EHLO for the past 10 years or more) text MUST be
either the sending server's FQDN or if it doesn't know its name its
IP address inside [...]. (On the other hand receiving servers MUST
NOT reject mail because they don't like the text. IETF committee
politics, I presume.
In the real world, using [IP-address] will get an attempt blocked
many places, and many receiving servers do block mail because they
don't like the EHLO text (some even block for saying HELO rather than
EHLO, although that's still authorized if frowned upon).
In your case, don't try to sharpshoot the problem: turn off
greylisting, wait for the message to come in, turn it back on, and
make a guess as to whether whitelisting the sending server will work
for future mail (whose timeliness may not matter as much anyhow).
Here, we give each user the power to turn greylisting on or off for
their account (default on). (We don't use Postfix--I have no idea
what Postgrey offers in the way of options.)
Oh...and you might as well whitelist--through greylisting--all the
Postini servers you learn about--they are going to pass greylisting
anyhow, so why delay the mail?
> ...SPF...
Enforcing can work for yourself (it can even work for enforcing ~all
as if it were -all, for yourself). It can work for a multiuser setup
if the users don't need to forward email through a server that
doesn't do SRS. It won't work for a server working for a mixed
audience.
We use SPF
1. as input in deciding on servers to whitelist through greylisting
2. to add some SpamAssassin points for failure in the case of
"trusted" (by us) domains (SpamAssassin points lead here to messages
going into Spam folders, not being rejected or dropped).
Note that MANY spammers (who may or may not adhere to CAN-SPAM)
carefully publish SPF for their domains. (Others carefully use DK or
DKIM.) Just passing isn't meaningful--passing and being a desired
sending domain is meaningful. Failing DKIM can be meaningful, but
watch out for mailing lists (the current Mailman causes problems by
stripping DKIM signatures, a reaction to the problems caused by not
doing so--next version will switch back).
--John
More information about the linux-list
mailing list