ietf-mxcomp
[Top] [All Lists]

Re: plan for april 5th xmpp conference...

2004-03-27 19:32:19

As a domain owner, my desire is to protect my domain from spoofing, and protect myself from receiving errant bounces (and virus warnings etc.) from messages I didn't send. In this role, I would like to state my domain's policy and have others check it against 2821 MAIL FROM (for bounces and other automated crap) AND 2822 From:, 2822 Sender: (for human-readable spoofs like phishing, and to cut down on misdirected abuse reports)

As a receiver, I would like to reject forged mail, so I am inclined to use whatever policy the sending domain would like to publish. It's a "would be nice" but not hard and fast requirement to be able to reject the message early in the SMTP phase. Since 2821 MAIL FROM allows me to reject a message before we even get to the DATA phase, I save on bandwidth (as well as threads/etc).

Of course I would like to also protect my users against forged 2822 From: (or to a lesser extent 2822 Sender:) so if there is a policy published for that, I would use it too.

So, for the reasons stated above I consider all of these valuable, and if I have to put them in order of preference it would be:

1>     2821 MAIL FROM  (to save bandwidth and provide relief to my mailer)
2>     2822 From:  and/or  2822 Sender:  (to combat phishing, etc)

These are a CLOSE 1 and 2 for me. I would feel that if we came up with a solution that handles one and not the other, that it's not a complete solution. I am willing to set aside one and write a Draft that only protects one of these, but I feel our work is not done as a group until we have addressed both, and I would hope that the mechanisms for both are compatible.


"2821 HELO/EHLO domain" has come up both on SPF-discuss and here. If there were a solution to detect bad HELO, and to publish enough info to keep MY domain from being used in a misleading HELO, I would use it, but I consider it less important. Also, I'm afraid of all the misconfigured systems out there with bad HELO... They need to be cleaned up, but I'm not going to push for that being a requirement because very few people see the HELO, I don't think users would think of it as a component of "identity".

(SPF uses HELO as a "fallback" if MAIL FROM: <> - that is a cool idea, but it makes the proposal a bit heavier and more complicated. Perhaps 2822 From: / 2822 Sender: would be a better fallback, since we have reasons to do that anyway?)

So for me HELO domain gets #3 with footnote "Optional"


I like the idea of MTA Mark, but my impression is that it sits in in-addr.arpa and just says "This is an MTA" or "Not an MTA", and doesn't have any way to map it to a forward domain. Is this correct? If so I would totally support it in its own right but it has very little value for me as a domain owner trying to protect my domain from being used it spoofing. There are spammers out there who control their own slice of in-addr arpa and can designate their spoofing systems as MTAs. Mark this #4.


--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>