Chris Fedde <cfedde(_at_)viawest(_dot_)net> wrote:
The common literature uses the terms Sender MUA, Sender MTA, Recipient
MTA, and Recipient MUA. I'm not sure that there is much to be gained by
changing the terminology.
I'm not proposing changing the terminology, I was just avoiding the
work of recalling yet another series of acronyms. I'll fix the
terminology...
I think that there is room for definitions of true sender and true
recipient too. Also I'm fuzzy on the difference between * and 0 in
your notation.
The '*' is intended to mean "the rule fits ANY value of consent at
this stage". It's less of a statement about the consent of the party
involved, than a short-hand for simplifying rules/
e.g. The description of the senders rule says (+,*,*,*), when the
recipient applies his rule (*,*,*,-), the result is (+,*,*,-). It's
basically "set intersection".
The end result is we have a shorthand description of the consent of
the parties involved. We know the sender consented, we know the
recipient did not. We don't know (and it may not matter) whether or
not the other parties consented, made no statement, or claimed
non-consent.
The Sender MTA may choose to throttle traffic from the Sender MUA on
grounds of self preservation but it seems unlikely that it would
implement any higher policy that prevents it from attempting to
achieve the senders desires.
I disagree. Unintentional open relays/proxies are (*,0,*,*). The
'0' in the sender MTA consent results in the sender MUA being allowed
to send spam. The relays consent SHOULD be (*,-,*,*). The '-' in the
sender MTA consent results in the sender MUA being prevented from
sending spam.
I tend to find this sort of quantitative analysis more productive,
and more informative than statements like "relays are bad!"
An algebra to describe spam will involve the recipients view of
email. Mostly it will require notations for functions on the feature
space of the email message and the recipients wishes.
Sure. But it should also be able to describe open relays, SMTP
sourcing from dial-up accounts when the ISP failed to prevent that,
etc.
I've found most of the discussion here focussed on the recipients
view of email. I would like to change that. My experience with spam
has been that there are other major players in the conversation who's
consent (or lack thereof) is being ignored in recipient-based models.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg