[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-07-04 16:53:31

From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>

You believe you might have misunderstood the RFC 2505 recommendation as
is consistent with the LMAP proposals,

LMAP is IRTF. darft form, not IETF.  R = research; not ready for
prime time.  None are standards or pending standards, or
Standards Track, or anything similar.  At best, Experimental.

I understand that Bruce and think you understand me too.  LMAP is not a
protocol. LMAP is a IRTF methodology based on research for which the
following IETF experimental drafts are based on:

IETF or no IETF, these are being implemented by vendors and operators. I
would not bet my boots they will be going away.  I don't pretend to be a
IETF expert, but given the security nature of the task and the heavy
principals involved,  I will probably bet these will become standard track
items in short order.

Do you plan to have any input on these experiments?

In other words, if the client IP is your address, then you have
NO business having my domain being used on your MAIL FROM,
because I did not authorize your IP address to use the return
path with my email domain.


Yes Really Bruce. Domain spoofing, forging is a real.

-- read 2505.  If you send to an external site which does
aliasing and sends back to some other local-part at the same domain,
guess what MAIL FROM will be; exactly as you set it.

I still don't think you understood.

First,  the LMAP based proposals is consistent with RFC 2505 SMTP client IP
address based rejection concepts.

Second,  RFC 2505 section 2.6.2 is outdated or not explicit enough in
regards to the types of MAIL FROM spoofs. For example, it doesn't discuss if
the spoof is based on a predefined SMTP client local IP association .  Why
would one want to use their email address to be used a return path by an
unknown remote site?  Why it is not doubt possible, it is technically
unsound, invites overhead on bounce activity and its most certainly,
invites security issues.  The experimental drafts do need to update this
section of RFC 2505 by clarifying the social network implication described
by the section 2.6.2 vs. an unknown IP social.

In short,  if one sends an email to some site with this specific planned
aliasing behavior,  this implies a predefined association or social network
of some kind.  This would be a clear white list case.

In my view, these extended checks should only be applied on 100% anonymous
sender unauthorized final destination mail.

If a legitimate sender is known to use your email for the return path in a
distribution, then you white list this predefined relationship.

If you don't expect this to be happening, then an LOCAL_IP::LOCAL_DOMAIN
association is perfectly sound with 100% trust and 0% false positives.


Hector Santos, Santronics Software, Inc.