ietf-mxcomp
[Top] [All Lists]

RE: sender_agents modifier

2004-08-06 23:50:28

On Fri, 2004-08-06 at 20:31, Jim Lyon wrote: 
The biggest problem with this is that most domains won't have enough
information to reasonably set "sender_agents".  Clearly, if your domain
permits people to send personal e-mail, it can't possibly know.

If they don't know, then they needn't enter information for that
address.  And if they want to know, they can just ask.  :-)

Right now it's quite common for ISPs to let their customers enter such
things as forward-to addresses via web-based control panels.

I'm sure they'll extend such functionality to allow customers to enter
their authorized sender-agents, just as I'm sure they'll extend the
functionality to allow their users to whitelist their forward-from (PRA)
addresses.

All the web page would have to do is ask.

For instance:

   What mailing lists do you subscribe to?  [Over time, this part should
                                             become more automated.]

                ________________________
                ________________________
                ________________________
                ________________________


   What email addresses do you always want to accept forwards from?

                The above mailing lists and:

                ________________________
                ________________________
                ________________________
                ________________________


   What email addresses do you allow to speak on your behalf?

           [ ] I allow everyone to speak on my behalf

           [ ] I make no claims one one way or another.

           [X] I allow only the following listed addresses
               to speak on my behalf:

               The above mailing lists and:

               _________________________
               _________________________
               _________________________
               _________________________
               _________________________


(Cool side issue:  With a sender_agents modifier, domain-based block
lists could become full-email-address-based block lists, blocking on the
email address if the email address participates in sender_agents, and
blocking on just the domain if it doesn't.)

However, I suspect that this inability to set "sender_agents" reasonably
won't prevent many domain owners from setting it unreasonably.

Therefore, I don't think it's a good idea.

Sorry, but that specific argument just doesn't fly.  :-)

There are probably other reasons you might disagree with the idea of a
sender_agents type of modifier, but it doesn't make sense for that
specific reason to be one of them.

The reason is that that same argument would apply to the %l (local-part)
macro variable.  Are you saying that you want to get rid of all
references to local-parts in the specs?  :-)

Do you really think a setting should be unavailable because of the
disadvantage that domain owners might set it unreasonably?  (Wouldn't
they lose business/customers if they did that?)

Compared to that disadvantage, look at the advantages that sender_agents
would provide:

Currently, recipient users and ISPs can only guess as to whether any
particular email is a forgery of the unauthorized-body-sender type. 

These are guesses, educated guesses, but guesses nonetheless. 

If we had sender_agents, then when the purported Header-From/forward-PRA
participates, recipients need not guess--they can *know*.

So when sender scammer(_at_)scammer(_dot_)example(_dot_)com sends a mail with 
header
"From: accounts(_at_)citibank(_dot_)com" and with themselves in the header 
Sender:
line, then a receiving MTA can safely reject the message, (yes, after
DATA--sorry!), no matter *what* other verification tests happened.

Or when spyware(_at_)spyware(_dot_)example(_dot_)com sends mail with header 
"From:
microsoftupdates(_at_)microsoft(_dot_)com", and themselves as the header Sender,
(presumably including in the message an html link saying something along
the lines of "click here to download the latest security patches"),
receiving MTAs can safely reject the message, no matter what other
verification tests happened.

In neither of the above cases would it need to matter that the MX
sending IPs of, or domain names of 
"scammer(_at_)scammer(_dot_)example(_dot_)com" or
"spyware(_at_)spyware(_dot_)example(_dot_)com", had or had not entered block 
lists
yet--if the companies listed in the header From:'s participated in
sender_agents with defaults of "not allows", then participating
recipients need never have any chance (absent DNS server hijacks and the
like) of being a victim of such scams.

In both cases, a sender_agents modifier would let recipients know that
the purported header From: party does not allow the later PRAs to speak
for it--it's a way of letting recipients know that messages such as
those are *not* authentic.

SPF/Sender-ID has always been focused around authentication, but with
the spec as it is, recipients don't have the information they need to
make this type of authentication test, and senders have no way of
publishing such information.

I suggest that it would be a good idea to allow people to publish
records about and run test for this type of forgery.

Please don't prevent the reliable detection of this type of forgery
merely because some domain owners will post inaccurate information about
how to identify what mails, purportedly sent under the authorization of
addresses in their domain, fall under this category of forgery.


<Prev in Thread] Current Thread [Next in Thread>