On 2007-01-22 09:35:38 -0700, JT Moree wrote: > Peter J. Holzer wrote: > >> http://www.pcxperience.org/jt/greenlisting.html > > > > Greylisting uses three pieces of information: The sender IP address, the > > sender email address and the recipient email address. Your proposal does > > whitelisting based on the sender email address. > > Not exactly. My proposal does not necessitate whitelisting for qpstmpd.
I was only talking about the effect on the greylisting plugin, so
"whitelisting" essentially meant "exempt from greylisting".
> To summarize, I don't want to change the whitelists that qpsmtpd is
> using--just the set of domains/IPs that are greylisted.
That's how I understood it.
> > People often have several email addresses, and when you send a mail to
> > one of them, you may get an answer from a different address (even from a
> > different domain). But since you then just fall back to normal
> > greylisting, it doesn't matter if this isn't foolproof.
> Does not matter. We are going to tell users to send an email to the
> address that the person is using who has complained about the bounce.
> That address will be resolved to an IP during the greenlist process.
I don't see how you would do that.
> > You may also want to be careful with autoreplies: If you have some
> > addresses which send automatic replies and which don't have greylisting
> > enabled, an automatic reply to a spam or virus mail may whitelist the
> > spammer for all recipients.
>
> This is a VERY good point and needs to be considered. . . . I'm updating
> the filters to skip mail from the mail server.
>
> > I don't understand the last paragraph in your proposal: If you whitelist
> > sender addresses, why do you need the sender IP address? Or do you want
>
> qpsmtpd works by IP address--not by domain names. The sender may be
> forged so it can't be trusted. Reverse DNS lookups are also unreliable.
There is no reliable way to get from a domain name to the set of IP
adresses which may send mail with with that domain in the return path.
For example, the MX for wsr.ac.at (my workplace) are
mx0.wsr.ac.at. 86400 IN A 143.130.16.110
mx1.wsr.ac.at. 86400 IN A 143.130.16.111
but if you get mail from my office address it will most likely come from
143.130.50.113 (so if you want to whitelist based on the addresses of
the MXs you'd have to whitelist a whole /18. I've seen cases where the
outgoing and incoming MTAs were in completely unrelated networks (they
may not even have the same owner, for example if a company uses an
external spam filtering service).
I think using the sender address is a lot more reliable: While it is
trivial to forge, the spammer doesn't know what address to forge, so he
is unlikely to hit one of the addresses which are currently whitelisted.
Also, you don't have to whitelist these addresses for ever: Your users
are expecting a response from them, so you can expire them after a
reasonable time (maybe a week or so).
So I would do it like this:
For all outgoing mails, determine the sender and all recipients and for
each recipient put a ($recipient, $sender) tuple into your greenlist. put
the (sender, recipient) tuple in your greenlist. (If you want to get
fancy, analyse the headers of the mail, and for each address in a
Reply-To or CC header, add ($recipient, $address), too).
Now, if an email comes in from $ip, with an envelope-from $sender, and
a recipient $recipient, check if ($sender, $recipient) is in your
greenlist. If it is, add ($ip, $sender, $recipient, WHITE) to the
greylist, and let the mail through. Otherwise, look up ($ip, $sender,
$recipient) in the greylist and proceed as normal.
So, essentially, I would whitelist on the email addresses, not on IP
addresses, because I can't think of a reliable way how to get sender IP
addresses from domain names.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | [EMAIL PROTECTED] |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
signature.asc
Description: Digital signature
