On 12/8/22 5:17 AM, Alessandro Vesely wrote:
Those who do so are neatly classified as spammers.
On one hand I agree. But on the other hand I disagree.One benign case is that [email protected] is configured to forward to [email protected] so that Alice A. can perform her function. Time goes by, Alice A. takes a job elsewhere. Some time later, Alice B. starts and decides to re-use [email protected]. All the while nobody cleaned up [email protected] which is still forwarding to [email protected]. Alice B. is in accounting and has nothing to do with and knew nothing about the [email protected] forward until she started receiving complaints that she couldn't help with.
A slightly less benign case was years ago when I was dealing with an AOL sender and AOL had no interest in doing anything to stop the sender. So I configured a forwarder to take messages from the sender, add them as an attachment to a message that cited the AOL internal case number to AOL's postmaster. AOL's postmaster had no hand in requesting the forward.
I consider both to be legitimate, non-spam, forms of forwarding in which the recipient had no hand in the forward being put in place and likely couldn't easily change it if they wanted to.
In addition, note that forwarded messages usually have a single recipient.
"usually" being the operative word.Remember, original incarnation of mailing lists started as multi-recipient forwards / expansions at the MTA level. Long before Mailing List Managers came into their own more proper existence.
Aside: I'll maintain that we are still suffering from such multi-recipient expansion legacy today as many still do not treat the mailing list manager as it's own proper first class email recipient and originator and instead still consider it to be a bump in the path.
This makes it reasonable to set up per-recipient whitelists.
Please elaborate on what "per-recipient whitelists" means in this context. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
