That's a diffent problem we'll have to discuss. Unfortunately,
it will be difficult to disestablish empty envelopes in
common SMTP.
Lots of bitter pills. RMX only solves the forgery problem and it
potentially breaks:
A. forwarding
B. sending off-domain #1 (the roving user using a remote ISP)
C. sending off-domain #2 (the local user using a non-controlled domain,
eg, I want to send email out from my ISP using my Yahoo address)
D. Raises the question of what to do with bounces
E. Probably requires a flag-day or implementation schedule. If RMX is
ever to be useful beyond categorizing email - ie actually rejecting
email as spam - then ISPs/providers will probably need to do this
in concert to a) get a lot of buy-in and b) avoid a customer
backlash like that experienced by Earthlink a month or so ago.
You could possibly address A) by doing envelope re-writing, but that's
currently considered bad-practice and presents a tricky issue for
subsequent bounces.
You could simply swallow the pill for B) and C) and say that's the
price we pay. (If RMX was close to a Silver Bullet, I for one would
happily accept the loss of off-domain mail submission.)
You could change SMTP to bounce with a semi-empty envelope, such as
<@example.com> to fix D) but that's more changes to SMTP.
And maybe if you try hard you might get the major ISPs/MSPs to agree
on a schedule to help E).
Then you're merely left with predicting how spammers will
respond. Will they adopt disposable/temporary domains making the
benefits of RMX largely moot? I doubt anyone knows for sure.
To my point.
None of what I've said has anything to do with RMX per se except to
suggest that any "solution" probably involves pills of varying
bitterness. Eventually we need to assess "solutions" based on:
o how bitter they are
o how effective they are
o how permanent they are
I especially worry that we under-estimate the ability of the spamming
industry to morph. We need to consider them as motivated, smart and
none-too-fussed about breaking a few laws. Any "solution" that assumes
otherwise is probably at risk of taking much longer to implement than
it does to defeat.
Regards,
Mark.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg