--Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
I think 2822 validation is a much harder problem and we will benefit
from some early success.
The first half of that statment is fact free, and the second half is
absolutely backwards.
You seem to have a problem with taking LMAP in smaller, discrete steps.
That's fine. However, please DON'T assume that when someone says "We
should do X first" that it automatically means "We should only do X".
People expect the standard we come up with to
substantially reduce spam flows (as recent press has confirmed). If it
doesn't, and IMO there's a big risk it won't, the result is LESS
credibility than we have now, not more!
Actually I don't know if either of these are true.
We've got <2822 validation is
too hard to tackle> (above quote)
Wait, I didn't say that, I said (and Marshall said) that doing three things
*at once* may be too difficult.
Well 3) was the RFC2822 stuff. The more I think about it and the more
I learn about the current state of the propsals in that area, the more
confident I become in saying that there isn't a clear solution.
That just proves my point. If that's a "strong argument for
elimination", I'm an 8 legged chicken. There has been valid criticism of
2822 stuff, but nothing like a strong argument for elimination. There has
been valid criticism of 2821 stuff, but nothing like a strong argument
for elimination.
Wait a second, nobody I have heard from said that we should eliminate 2822
solutions. This just says that those solutions are not yet as mature and
as available. Everyone seems to agree that 2822 is important (due to high
visibility to the user).
2822 checks are NOT too complicated, or much more complicated than 2821
checks. What's the time it'll take this to be hammered out compared to
the time to get MARID broadly deployed? Nothing.
Probably true. I still would agree with Marshall that trying to do BOTH at
one time is more difficult.
Now. That said, I don't have a *strong* preference for tackling one and
delaying the other. I think it IS possible to do both (and the third,
HELO) BUT as I said, more difficult and by tying them together you don't
have the benefit of showing some results earlier than others. I'm not
afraid of difficult work or of waiting longer for results.
Apropos Andy Newton's comments: this is inane. The IETF is NOT about an
anonymous group dictating how things are gonna be with public discussion
being nothing but a rubber stamp. I feel like a spam beneficiary is
setting the agenda behind the scenes! It seems like we're working hard
to AVOID coming up with a really good solution. We've already seen what
happens when folks implement (what 20/20 hindsight shows were) seriously
flawed antispam schemes, such as C/R, banning open relays, etc. It seems
like some folks are content to create another JAHCASS
(JustAnotherHalfCookedAnti-SpamSolution?)
Whoa, be careful with the emotionally charged statements. Disagreement
doesn't make someone an enemy automatically, even if you feel strongly.
Officer Andy is wrong. It is
absolutely not forbidden for us to endorse a scheme that implies a
suggested tighenting up on what is allowed in SMTP.
Actually I agree with you here (and I disagree with Andy's interpretation).
If we publish MTA authorization records in DNS, and don't tell receivers
what to do with them, we haven't really fixed anything. Either receivers
read the info and do whatever they want (which is chaotic or at least
quixotic) or receivers are not allowed to do anything with the information
(for example, 2821 says HELO should be a fqdn but we MAY NOT reject it if
it's not) and it's kind of useless.
I really would like to get a strong recommendation for receivers out of
this group. Just publishing a list of MTAs in DNS is easy (I already did
that with SPF) but I don't think that will be useful to anyone if left
alone.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>