Re: [Asrg] Adding a spam button to MUAs
2010-02-04 15:47:06
Alessandro Vesely wrote:
On 03/Feb/10 17:45, Chris Lewis wrote:
Removing the ones it doesn't want the client to respect and/or rewriting
the ones it does want the client to respect, or simply replacing them
all with its own is the best way of doing that.
Like removal of "Received" traces, this shouldn't be done frivolously.
It's never stopped Microsoft :-E
I'm envisaging a situation where the email as received by the UA has one
or more sets of instructions of how to send a TiS report, and where.
_Most_ of the time it _may_ be the MUA communicating back to its MTA
(perhaps by IMAP). The MTA can simply insert those as per site policy.
But the MTA may choose to allow upstream instructions through as well
(if it chooses to trust them).
It filters off any maliciously forged Authentication-Results bearing
its own authserv-id, but they wouldn't have provided a different
target anyway.
Why not? Why wouldn't a scammer attempt to divert the recipient's TiS
buttons to /dev/null, DDOS someone else, or divert complaints away from
their provider who might zap them?
That's not possible: the authserv-id is just a naked token.
It can if the instructions contain where and how to report.
For simplicity, you may well want to have the core specification require
that the receiving MTA makes all the choices at transit time, and
removes all forwarding instructions that it doesn't agree with.
Hmm... I like the idea that an MTA may acknowledge ARF reports in
transit,
I'm specifically referring to the MTA indicating _which_ TiS
"instructions" the MUA is permitted to follow (perhaps simply by
removing whatever instructions it elects not to permit). Not
necessarily that the MTA send the ARF reports. In fact (as below), it
wouldn't be the MTAs that send an ARF report in my infrastructure.
Slight alterations of messages that give corporate acknowledgments are
quite usual, e.g. footers and DKIM signatures. However, changing a
message's destination is not common, AFAIK.
I'm not talking about altering destination of the message. I'm talking
about altering/replacing the destination of an abuse report.
Besides, spam filters change destinations all the time.
The client can rely on the fact that all messages in a given mailbox
have been received by the relevant server. However, a server doesn't
know that an ARF contains a message that it had previously delivered
to the reporter. This is different from webmail.
Doesn't necessarily need to, especially if it's told/allowed the MUA to
send the report directly.
The indirection may well be desirable, but you have to ensure that it is
convenient to do so (in other words, make sure that the client's
provider's AR handling _know_ what routing decisions they're being asked
to assess and implement).
Well stated. Policies and experience are essential here, but it would
be desirable to have a set of easy rules that a newcomer may/ should
follow in order to behave correctly. Perhaps, presentation of new mail
domains and reputation tracking will eventually be specified.
I don't think we want the user to be involved at all, aside from pushign
the TiS button.
As for tying an MTA to abuse reports handling, I think it is the most
convenient choice. The kind of spam that we may be able to control by
properly routing ARs does not require the immediateness of HTTP.
The MTA is only essential to abuse report handling insofar as the abuse
reports may adjust the filters.
Not only that. User IDs and authentication methods may be specific for
mail apps. We should follow ease of development and deployment.
As long as you don't force it.
It'll be convenient to do the AR
handling on the MTA in some instances, but in many it will be not a good
choice. A specification design that makes AR handling independent of
the MTA is a better one. You can run it co-resident if you wish. But you
don't have to. Making the spec require too much of the MTA function
would be a mistake in that regard.
Some task may deserve a different tool, of course. However, making the
spec too general, e.g. reporting spam using different transports, may
become cumbersome.
This has nothing to do with transports, but everything to do with
destinations.
Do you have a specific case in mind?
Yes, mine. As many as 11 dumb front end SMTP filtering engines in DMZes
firewalled off like crazy. Internal infrastructure a mixture of O/S and
MTA technology run by a different group. and has dozens of mailbox
servers (mixture of IMAP, POP and Microsoft stuff).
Filtering engines managed by centralized filter control server, which
manages quarantine, abuse complaints, logging, FP mitigation, and all
filter adjustment.
Bad idea to put much intelligence on the DMZes of any kind. These things
really are dumb - SMTP in, SMTP to infrastructure, control & log
exchange with control server. No mailboxes, IMAP, POP or anything. No
persistent message data of any kind - no spool, even logs are highly
transient.
[If one of these blows up, I reinstall the software on bare machine, hit
"go" and it's back in operation. Truly appliances.]
Have zero access to internal infrastructure. Would have to replicate
and manage TiS extensions on them all.
We treat abuse management/spam as an independent overlay on top of the
internal infrastructure. I don't bug them, they don't bug me ;-) It's
entirely internal infrastructure/technology independent.
[The filtering infrastructure is designed that way, originally as a
potential product, without having to alter the customer's internal
machines. That's not going to happen now.]
The logical place to implement abuse reporting mechanisms is on the
control server, and I've already dabbled in that. They don't even have
to be user-initiated. Have a filter say "this message came from a BOT",
automatically the control server sends a notification.
Our TiS button consists, in the main, getting a filter-generated
message-id (not RFC2822 Message-ID) back to the control server, and it
can identify everything it needs to know about the email from that.
Today, it's by simple forwarding of the message to an alias on the
control server, and the ID is scraped from that. A simpler mechanism
using existing tools would be a simple HTTP GET with a ID parameter, but
tying that to a UA button is hard (unless it gets standardized). If it
were standardized, could use a entirely different protocol. Even a
single short UDP packet would do the trick.
The filters could have rules on how to add/adjust inbound abuse
reporting instructions. I'd like nothing more than to accept/implement
"forward to X" instructions from sites I trust. Whether the MUA or the
control server actually executes the instructions I don't care that much.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Asrg] Adding a spam button to MUAs, (continued)
- Re: [Asrg] Adding a spam button to MUAs, Ian Eiloart
- Re: [Asrg] Adding a spam button to MUAs, Steve Atkins
- Re: [Asrg] Adding a spam button to MUAs, Bart Schaefer
- Re: [Asrg] Adding a spam button to MUAs, Chris Lewis
- Re: [Asrg] Adding a spam button to MUAs, Alessandro Vesely
- Re: [Asrg] Adding a spam button to MUAs, Chris Lewis
- Re: [Asrg] Adding a spam button to MUAs, Alessandro Vesely
- Re: [Asrg] Adding a spam button to MUAs, Chris Lewis
- Re: [Asrg] Adding a spam button to MUAs, Alessandro Vesely
- Re: [Asrg] Adding a spam button to MUAs,
Chris Lewis <=
- Re: [Asrg] Adding a spam button to MUAs, Alessandro Vesely
- Re: [Asrg] Adding a spam button to MUAs, ram
- Re: [Asrg] Adding a spam button to MUAs, Al Iverson
- Re: [Asrg] Adding a spam button to MUAs, Ian Eiloart
- Re: [Asrg] Adding a spam button to MUAs, Chris Lewis
- Re: [Asrg] Adding a spam button to MUAs, Steve Atkins
- Re: [Asrg] Adding a spam button to MUAs, Michael Thomas
- Re: [Asrg] Adding a spam button to MUAs, John Levine
- Re: [Asrg] Adding a spam button to MUAs, Ian Eiloart
- Re: [Asrg] Adding a spam button to MUAs, John Levine
|
|
|