ietf-asrg
[Top] [All Lists]

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