|
Re: Limited scope of work
2004-04-01 21:44:05
Greg Connor wrote:
the proposed mailfrom checking schemes do nothing to prevent a spammer
from creating useless addresses and placing them in mailfrom.
so the scheme merely blocks one particular kind of spammer abuse,
which spammers will be able to nicely route around.
--Gordon Fecyk <gordonf(_at_)pan-am(_dot_)ca> wrote:
We're not blind to that.
I'm going to jump in here because it's the most common argument I see
against envelope checking - that a spammer or other evil-doer is going to
find a new way to work within the system.
The idea is to make them accountable for doing it. As in, "really, these
guys who operate example.com are abusing e-mail."
I agree with Gordon. (Yes, I'm doing a lot of agreeing today. Trying
to set an example I guess :)
Remember, the thing we are trying to tackle is to force everyone
(spammers included) to use their own domains - or at least not abuse
*mine* if I opt-in for protection.
...
In other words, checking MAIL FROM is good for forgeries, and is in my
opinion "necessary but not sufficient" for a multi-step multi-solution
approach to spam in general.
This was also mentioned in the LMAP discussion document - that this type
of checking is only one tool in the toolbox. Another argument which
people made is that just like in cybersecurity it is important to make
the playing field smaller by closing certain mechanism unavailable to
spammers. They will surely find a way around it, but their range of
options will be smaller. Combine that with other mechanisms attacking
other aspects of the problem, and the noose is becoming even smaller.
Absent other substantive changes, such as widespread addition of
dynamic DNS capabilities, they make SMTP work only as a direct channel
between the originator's site and the recipient's site.
Is this a bad thing?
It is a major change so we would need to justify it. So it would be
helpful if we are aware of the changes we are imposing and have reasons
to go along with them. For this specific example, changing SMTP to act
as a direct channel instead of hop by hop (except in cases that John
Leslie mentioned) is a change. The reason for this change stated so far
has been the need to force domains to take responsibility for bounces so
they are not redirected to someone else.
All I am trying to say is that simply stating feeling might not be
sufficient, we need to spell out clearly why we feel (or some of us)
that specific changes are warranted, and that the benefits gained by
those changes will outweight the potential costs.
Actually, it's NOT a forgone conclusion that mobile-but-legitimate or
other dynamic approaches will break. Dynamic dns updates are one
possible solution, not even the most attractive. I think the most
attractive solution is what's presented in RFC2476, connect to your
normal MSA on the SUBMIT port. Using your mobile or home ISP for
return-path/MAIL FROM but asserting your own From: address is another
option.
Options abound. The misconception that MAIL FROM checking "breaks"
mobile sending has been referred to a lot, but I don't think it's an
axiom. I think the majority of users might not notice, other than
having to turn on SMTP AUTH and enter their password again.
Folks can still do clever stuff, like add permit records to their DNS on
the fly, sort of a "pop-before-MARID" clever thing is possible... but
it's not required for most implementations, I think.
If we could come to some agreement about mobile users, I think that
would help frame ongoing discussions. How about this proposed language:
MAIL FROM checking might affect some mobile users. The flexibility of
being able to send mail from anywhere is good for mobile users, but that
same flexibility is well-abused by forgeries as well.
Multiple solutions to this problem exist; in most cases, mobile users
should make sure that they have access to an MSA (port 587) that uses
SMTP AUTH. Other solutions include using your home or mobile account as
the Sender: while keeping your preferred address in the From: header
(similar to what mailing lists do), or using VPN or web mail while on
the road.
There may be other solutions to this problem as well. It is the
responsibility of the domain owner to provide appropriate solutions for
all authorized senders before publishing outgoing LMAP policies that
might exclude them.
Feedback on this language is appreciated... I am hopeful that the
mobile-user issue doesn't become a show-stopper for MAIL FROM
checking... I'm pretty sure that most domain owners would happily deal
with SMTP AUTH or other appropriate solution if it means their domain
will be protected.
The LMAP discussion document has an entire section on this
(http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-00.txt,
section 3.2) with a list of solutions which may make your language
unnecessary.
Yakov
|
|