|
Re: [Asrg] draft-irtf-asrg-criteria is missing Outbound MTA definition.
2009-06-29 14:54:48
On Jun 29, 2009, at 1:12 AM, Ian Eiloart wrote:
--On 26 June 2009 11:37:21 -0700 Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>
wrote:
This draft fails to include a definition that encompasses a crucial
and safe point of control essential for effective spam mitigation.
The missing definition is that of the Outbound MTA, the entity
granting access and facilitating public SMTP exchanges to other
domains. Email-Arch's definition tends to understate the role with:
Outbound MTA, an MTA that relays messages to other ADMDs.
Defining an "outbound MTA" would be useful, I guess.
See:
http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor9
A definition for spam sources should acknowledge RFC 5321 Sender is
not the _only_ identifier that might be used to manage spam. It may
even prove impractical or unsafe to attempt to check where a message
may have been created and initially entered, as Section 1.3.1
definition for Sender seems to imply.
This Sender definition runs afoul of several SMTP concepts. The RFC
5321 Sender does not define persons, automated-systems, or groups that
create or enter messages. The Mail command defines an error
notification path (reverse-path) and not a person, automated-system,
or group responsible for having created or entered the message. In
fact, the error notification path might be NULL in some cases. This
can not be referring to the EHLO command, since this would be the SMTP
client, and not not a person, automated-system, or group responsible
for having created or entered the message. By even using the word
"Sender" and implying this identifies a person, automated-system, or
group responsible for having created or entered the message confuses
RFC 5321 identifiers with those of RFC 5322. One might assume that
redefinition of RFC 5321 is the underlying intent of this draft.
Rather than misusing the term "Sender", perhaps the term "RFC 5321
Originating Identifiers" would be better. A list of Originating
Identifiers could include those expressed by either RFC 5321 MAIL or
EHLO commands.
Omission and erroneous definition may have a tendency to preclude
other options. While no one likes to find the outbound MTA they are
using has been blocked for policy reasons, it is often possible to
rectify this by obtaining access to a different outbound MTA. When
the domain used in an email-address is blocked for policy reasons,
rectification may require abandonment of the email-address domain
instead. There are no perfect solutions. Policy based upon the EHLO
command, rather than the Mail command, may provide more efficacious,
practical, and scalable solutions than policies based upon the MAIL
command. This draft should not preclude the use of the EHLO identity,
nor misconstrue MAIL command assertions.
What level?
The paper isn't discussing particular proposals, but you seem to be
saying that it should. It's discussing certain desirable properties
of proposals. Perhaps you're looking for more detail, or something
closer to an actual solution.
The draft should drop its current definition of Sender. Spam does not
just originate from purported RFC 5321 Senders, nor is it safe to
assume that an MTA authorization referenced by an RFC 5321 Sender
asserts where a message was initially created and entered.
Authorization does not provide this property.
If you want to say that a desirable proposal would be scalable, then
that's fine. If you want to say that SPF doesn't scale for a
particular reason, then that's outside the scope of this proposal.
Stronger statements along the lines of scaling might be helpful. It
seems increasing potential DNS transactions by an order of magnitude
or more has not been given adequate consideration in some anti-spam
efforts. :^(
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
|
|