ietf-mxcomp
[Top] [All Lists]

RE: Can you ever reject mail based on RFC2821 MAIL FROM?

2004-04-23 08:57:19

Thus far I've come up with exactly zero cases where RFC2821 MAIL FROM by
itself can be used to reject mail.

So I'm asking for your help.  When, if ever, can this be done?

None of the proposals tabeled so far use MAIL FROM _only_ - that much is
certain.  They also use the client's network address.  DMP also uses HELO as
a fallback to support forwarders - the exact problem you've asked us to
solve.

Come up with a scheme or set of conditions that enables receivers to
correctly reject messages based solely on RFC2821 MAIL FROM.
This scheme must work in the face of forwarders who have not implemented
SRS, VERP or any similar mechanisms

Admittedly, this in and of itself is impractical (I won't say 'impossible').
It's why DMP has a fallback.

Here's at least one scenario where a "conservative" DMP site would reject
mail based on MAIL FROM:.  Yes, it checks the host too, as supporting
evidence for the MAIL FROM check.

5.8 Participating Domain's User, Not Participating Domain's Client
    (dmp=deny, NXDOMAIN)

   S: 220 mail.example.net MMS SMTPRCV service v0.95
   C: HELO othersender.example.org
   S: 250 mail.example.net Hello othersender.example.org [192.0.2.7]
   C: MAIL FROM:<user(_at_)example(_dot_)com>
   (server looks up 7.2.0.192.in-addr._smtp-client.example.com
   and receives "dmp=deny")
   (server looks up
   7.2.0.192.in-addr._smtp-client.othersender.example.org
   and returns NXDOMAIN)
   (server looks up _smtp-client.othersender.example.org and returns
   NXDOMAIN)
   S: 550 ERROR client at 192.0.2.7 may not send for example.com
   [resume as though MAIL FROM had not occurred]

Here's a similar scenario, where the host (in this case a host being spoofed)
as well as the domain happens to have DMP records:

   S: 220 mail.example.net MMS SMTPRCV service v0.95
   C: HELO othersender.example.org
   S: 250 mail.example.net Hello othersender.example.org [192.0.2.7]
   C: MAIL FROM:<user(_at_)example(_dot_)com>
   (server looks up 7.2.0.192.in-addr._smtp-client.example.com
   and receives "dmp=deny")
   (server looks up
   7.2.0.192.in-addr._smtp-client.othersender.example.org
   and returns NXDOMAIN)
   (server looks up _smtp-client.othersender.example.org and receives
   "dmp=")
   S: 550 ERROR client at 192.0.2.7 may not send for example.com
   [resume as though MAIL FROM had not occurred]

...and, if the DNS folks would excuse my ignorance for a moment, where the
host (being spoofed) happens to have some wildcard records that actually work
and aren't obscenely stupid:

   S: 220 mail.example.net MMS SMTPRCV service v0.95
   C: HELO othersender.example.org
   S: 250 mail.example.net Hello othersender.example.org [192.0.2.7]
   C: MAIL FROM:<user(_at_)example(_dot_)com>
   (server looks up 7.2.0.192.in-addr._smtp-client.example.com
   and receives "dmp=deny")
   (server looks up
   7.2.0.192.in-addr._smtp-client.othersender.example.org
   and receives "dmp=deny")
   S: 550 ERROR client at 192.0.2.7 may not send for example.com
   [resume as though MAIL FROM had not occurred]

-- 
PGP key (0x0AFA039E): 
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>