On 4/26/04 at 12:15 PM -0700, Harry Katz wrote:
No. The receiver must whitelist based either on the IP address of
the forwarder or on the HELO domain. This does mean that you can't
just set up a .forward to a receiving system that implements MARID
checking without the admin of that system doing such a whitelist
entry.
In the future, you could use the ORCPT parameter as the check if
folks would implement it for forwarding.
To go back to your original question, yes, you can reject mail
based on 2821 so long as you are willing to tell your users "You
can't forward to here unless you tell me from where you're
forwarding."
That's a reasonable position if you're asking users to tell you the
email addresses from where they're forwarding.
One way to accomplish using the e-mail address is use the ORCPT
parameter as I mentioned above. The other way is to make sure that
the domain on the RHS of the e-mail address has MARID DNS listings.
If it does, then:
- The forwarded user supplies you with their forwarding e-mail address.
- You put their local e-mail address and the domain of the forwarding
e-mail address in your forwarders whitelist.
- When you get a MAIL FROM that fails (assuming you have entries in
your forwarders whitelist), you wait for the RCPT TO, see if the
local e-mail address is in your forwarders whitelist, and if it is,
you do a MARID lookup on the domain of the forwarding e-mail address
and see if the IP address is OK. If it is, accept the message; if
not, reject.
This does mean that you have to wait until after the MAIL FROM for
the RCPT TO to reject if you've got a forwarders whitelist, but I
assume you're not arguing against that?
It's not reasonable if you're asking end users to supply the IP
address or HELO domain of the forwarder's MTA. It's also not
reasonable if you're asking the receiver's MTA administrator to find
and maintain that information -- that won't scale.
If you wanted to do a HELO based whitelist, I don't think it's
unreasonable to expect forwarders to provide the RHS of the
forwarding address in the HELO argument. Therefore the user can just
give you the e-mail address. I agree with you that expecting to get
an IP address or HELO domain otherwise is not scalable.
If the forwarder is not doing MAIL FROM rewriting, then even with
whitelisting you can't reject based on 2821 because the forwarded
address doesn't appear in MAIL FROM, only the original sender's
address.
Nonsense. As I explain above, you can do HELO whitelisting if it's
set up appropriately, or e-mail address based RCPT TO whitelisting,
or ORCPT whitelisting.
If the forwarder IS doing MAIL FROM rewriting, what precisely is it
that the receiving user is supposed to whitelist? The rewritten
address containing a randomly inserted cookie? The forwarder's
entire domain?
I have no idea what this means.
Whitelisting does not work for MAIL FROM in either case!
I really wish it were possible to reject reliably on a spoof check
of MAIL FROM, but it just isn't folks. It just isn't.
I'm sorry Harry, this just simply isn't true. You're not thinking out
how the whitelisting will go. Having a list of IP addresses is not
the only way to whitelist.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102