-----Original Message-----
From: Pete Resnick [mailto:presnick(_at_)qualcomm(_dot_)com]
Sent: Monday, April 26, 2004 2:54 PM
To: Harry Katz
Cc: ietf-mxcomp(_at_)imc(_dot_)org
Subject: RE: Can you ever reject mail based on RFC2821 MAIL FROM?
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?
None at all. This is an interesting idea. The fact that it uses more
information than just the MAIL FROM seems like the right direction. I
need to look into this some more.
I do have a concern about whitelisting the entire forwarding domain.
There are some awfuly large domains out there that do forwarding. I'm
not sure how many administrators would be willing to whitelist some of
these. However, that could be a local administrative choice. And I'll
be the first to say that letting in too much is better than rejecting
too much.
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.
Perhaps not. In many cases, though, a single MTA may forward on behalf
of multiple domains. The end user who sets up the forwarding
arrangement may not know what domain name is used by the forwarding MTA
in HELO/EHLO.
[snip]
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.
This means I had a temporary fit of insanity. Please ignore.