foo@user.scripts.mit.edu should equal user+foo@scripts.mit.edu

[quentin]

We should make foo@… deliver mail to user+foo@….

[andersk]

scripts: quentin filed a new ticket: foo@… should equal user+foo@… We should make foo@… deliver mail to user+foo@….

quentin: Enjoy :)

andersk: What good is the +foo? You can already filter on the To: address...

andersk: Also, you shouldn't destroy information if I try to send to foo+bar@…

geofft: Yeah, s/to/as if it were to/, like vhosts.

andersk: Like I said, I don't think I agree that the +foo should be added. What happens right now when you alias foo@… to geofft?

andersk: Adding @andersk.scripts.mit.edu andersk to /etc/postfix/virtual gives me messages with

X-Original-To: foo+bar@andersk.scripts.mit.edu
Delivered-To: andersk@scripts.mit.edu

That seems sufficient for procmail matching. So all we need to do is shove /etc/postfix/virtual into LDAP.

geofft: FUSE!

andersk: I mean, the LDAP solution would work, and would probably take like an hour to implement.

andersk: But there's one thing I'm concerned about. Currently, if I'm told to email studentgroup-request@…, I can blanche studentgroup-request to figure out who my email would go to. But in a world where studentgroup has moved their email to request@… hosted on scripts, this is no longer possible.

geofft: That's not necessarily true; it could be private. (Ignore sketchsis.)

andersk: But I don't want it to be private by _default_.

geofft: scripts-pony will let you make your vhost entry published, visible, or private.

andersk: If the path for email is

request@studentgroup.mit.edu -> studentgroup@scripts.mit.edu -> procmail -> studentgroup-request@mit.edu

then it doesn't matter: even if the first arrow is public, the procmail script isn't, and I wouldn't want to read it even if it was.

andersk: Therefore, if we implement this feature, I'd like to see the ability for users to add arbitrary entries directly to the virtual map, and make the virtual map public.

request@studentgroup.mit.edu -> studentgroup-request@mit.edu

geofft: See also, scripts-pony.

andersk: Right. I'm arguing that this should block on (that portion of) scripts-pony being implemented first.

geofft: You don't think people will go back and make their lists public if we start them off as private?

geofft: Also, we can block _advertising_ this

andersk: No, people are too {stupid,lazy,greedy,evil} to care.

andersk: Until we implement scripts-pony, I would be happy with putting the virtual map in ldap but *not* populating it with any default entries; and manually accepting new entries (for either *@domain or user@domain).

geofft: Hm. wserv/lc has lists visible by default.

andersk: As it should!

andersk: The virtual(5) manpage makes another good point. "Note: @domain is a wild-card. With this form, the Postfix SMTP server accepts mail for any recipient in domain, regardless of whether that recipient exists. This may turn your mail system into a backscatter source: Postfix first accepts mail for non-existent recipients and then tries to return that mail as "undeliverable" to the often forged sender address."

quentin: I should make it more clear what I intended; foo@… should deliver the mail to bar's procmail script with $1 set to "foo", as bar+foo@… currently does. I don't think we should actually do any forwarding or header wewriting.

andersk: I agree that's what you intended, but I don't agree that's right.

quentin: Also, people mentioned bar.mit.edu. We can't handle mail for custom domains, because those are CNAMEs, not As.

andersk: It's possible that we could fix that if we asked really nicely. Otherwise, s/studentgroup.mit.edu/studentgroup.scripts.mit.edu/ in my comments.

andersk: Also, non-.mit.edu domains will work fine.

[quentin]

We now support mail to foo@…; it internally redirects to bar+foo@…. This is documented at http://scripts.mit.edu/mail/.

[andersk]

As far as I can tell, the draft implementation ignores all the concerns I previously raised on Zephyr (see the first comment), and was not committed. I don’t intend to be mean, but we should have a discussion about this, so I’ll reopen this ticket for now.

[quentin]

This implementation does indeed address all the concerns raised, and was committed in r983. No information is lost when the message is delivered; the original headers are all preserved. Internally, the mail is redirected to user+tag, but that doesn't change any of the original headers.