[Rwp] Why the From: field is set to the list itself

[Matej Golian]

Jayson, thanks for the nice explanation.

2015-02-05 18:32 GMT+01:00, Chris Belle via RWP <rwp at bluegrasspals.com>:
> Thanks for the primer 'grin'.
>
> On 2/5/2015 6:52 AM, Jayson Smith via RWP wrote:
>> Hi,
>>
>> I know about the From: field of list messages being set to the list
>> itself. This is yet another thing legitimate list owners have had to
>> do in the ongoing fight against spam. I'll explain why, but hold on to
>> your hats, this is going to get pretty technical.
>>
>> First, some terms you need to know before we get started. Many of you
>> probably already know some of these, but just so everybody is on
>> common ground, here we go.
>>
>> Internet Protocol address or IP address: This refers to a specific
>> point on the Internet. It's sort of like a telephone number computers
>> use to contact each other. An example is 96.126.127.231.
>>
>> Domain name: This is the human-friendly representation of a computer's
>> address on the Internet. Examples are Google.com, whitehouse.gov, and
>> barbershop.org. Most if not all Internet users use these every day
>> without even thinking about it.
>>
>> Domain Name System or DNS: This is sort of like a phone book for
>> computers. A computer can contact DNS and say, "I have a user who
>> wants to go to google.com, what's their IP address?" DNS then returns
>> the IP address or a response saying there's no such domain name. The
>> computer then contacts the IP address directly. This goes on behind
>> the scenes, and the user is not involved. Additionally, domain owners
>> can publish other types of records in their DNS, which we're about to
>> see.
>>
>> Sender Policy Framework or SPF: A record published by a domain owner
>> in DNS, specifying which IP addresses are permitted to send mail from
>> that domain. Mail servers can check incoming mail against such a list
>> as part of their determination of whether any given message is spam.
>> For example, my domain, bluegrasspals.com, specifies in its SPF record
>> that 96.126.127.231 is the only server allowed to send mail on its
>> behalf. If a message comes in somewhere claiming to be from
>> bluegrasspals.com, the receiving mail server can check the SPF record,
>> and if the sending IP address isn't on that list, the from: line is
>> probably forged, which means the message is more likely to be spam.
>>
>> DomainKeys Identified Mail or DKIM: Another method of message
>> authentication. In this system, a domain owner who wishes to send mail
>> generates a pair of cryptographic keys, one public, the other private.
>> They publish the public key in their DNS record, and keep the private
>> key on their server. After that, they attach a cryptographic signature
>> to the headers of every message they send from that domain, based on
>> that private key. Mail receivers can then check that signature against
>> the public key stored in DNS, and if the signature checks out, this
>> tells the receiving system two things. First, that the domain claiming
>> to send the message actually sent it, since presumably only servers
>> under the control of the domain owner have the private key needed to
>> generate signatures. Second, that the message has not been modified in
>> any way since it was signed. This is yet another way to estimate the
>> likelihood of a message being spam.
>>
>> Domain-based Message Authentication, Reporting and Conformance or
>> DMARC: Finally! The reason for this entire discussion! DMARC is a
>> system whereby domain owners can publish a policy in their DNS
>> records, specifying how compliant receiving systems are to handle mail
>> claiming to originate from their servers, but which fails SPF or DKIM
>> checking. The available actions are to ignore the problem, quarantine
>> such mail, or outright reject such mail.
>>
>> And now we come to the problem for list owners. Certain large ISP's in
>> particular, Yahoo! being one of them, have published DMARC records in
>> their DNS which instruct receiving mail systems to reject mail
>> claiming to come from those domains, but which doesn't pass SPF or
>> DKIM checks. An example might help.
>>
>> You have a Yahoo! account. You send a message to my mailing list that
>> lets the From: field of its outgoing messages go through unmodified.
>> My server receives the message, processes it, and sends it to all my
>> list members. So off the message goes on its way, but then it hits a
>> provider which uses DMARC as a way to authenticate messages.
>>
>> Okay, we have a message claiming to come from Yahoo! Let's check to
>> see if it's legitimate. Does the sending IP address appear on Yahoo's
>> SPF record? Um, let's see. Wait, no, it doesn't! Okay, what about
>> DKIM, is that valid? Checking, looking... Nope, that's not valid
>> either! Now, does Yahoo! tell us to do anything special when this
>> happens? Let me see...here it is, yes, I should reject this message!
>>
>> And it tells my server, "Sorry, but I'm not going to accept this
>> message from you because you're probably a spammer trying to forge
>> Yahoo! addresses."
>>
>> For clarification, the reason the DKIM check didn't pass is that,
>> while Yahoo! almost certainly signed the message when it was
>> originally sent, my mailing list software messed with it in the
>> process of getting it ready to send to the list, so the signature was
>> no longer valid.
>>
>> The solution to this problem is to set the From: address of outgoing
>> list messages to the address of the list itself, which is safe. When
>> this happens, any authentication policies put in place by the original
>> sender of the message never come into play, since my server is no
>> longer seen as trying to forge those addresses.
>>
>> Unfortunately, Mailman, the mailing list software I use, requires a
>> list to either allow the From: field to go through intact, or change
>> it to the list address, for all list posts. You can't isolate specific
>> problem domains, it's either all or nothing. Another option I
>> considered was putting the sender's Email address in the list footer,
>> so people could write privately if desired, but guess which bit of
>> text Mailman does *not* allow as a substitution? That's right, the
>> sending address!
>>
>> I could turn this feature off on a trial basis and just see how it
>> works, but this would probably cause some mail to start bouncing. What
>> do you guys think?
>>
>> Sorry this has been so long, but I felt it necessary to insure
>> everyone had the proper background knowledge to understand the
>> problem, and the solution.
>>
>> Jayson
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>>
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp
>