Iam using mailman3 and I just want to set a FROM name for my lists. Currently the FROM for lists for example the welcome mail etc. is just the mailaddress like LISTNAME#lists.example.com but I would like to have it like My List <listname#lists.example.com>. I could not find the correct setting here:
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs/config.html#schema-cfg
to achieve that and hope there is a solution for that
The mailing list display name is not used when sending service emails (like the welcome email). Also, they are being sent from addresses like listname-request#lists.example.com rather than from the main list's address.
Certain emails like (un)subscription notifications might be sent from an email defined in the site-owner parameter, but they are for list owners, not regular members.
Related
This is the Scenario:
In the same Azure tenant, I used one account (user_1_address) to send emails to the other account (user_2_address) using outlook (o365).
I sent 3 emails, one where user_2_address is BCCed, one CCed, and one when it's the TO recipient.
I'm using Microsoft graph API to get a list of emails received by user_2_address in a specific time range, using this query:
https://graph.microsoft.com/v1.0/users/{<user_2_id>}/messages?$filter=
receivedDateTime ge <some date> and receivedDateTime lt <some other date>
and isDraft eq false
and sender/emailAddress/address ne '<user_2_address>'
I'm getting all the three emails user_2_address had received from user_1_address. But in the email user_2 was BCCed the bccRecipients list is empty, when it should contain user_2_address :(
I have seen this question about sending an email from Gmail and BCC an outlook user:
Microsoft graph API: empty BCC field
In that case, also the bccRecipients list was empty, but it was resolved by saying the BCC is removed when sending the emails from an external source (Gmail in that case). When for me it's not an external source - both users are using outlook in the same tenant.
So my questions are:
Is it the desired behaviour, or is it a bug?
Now, let's say I'm using the query above where I get all emails where the sender is not the user_2_address and it's not a draft. Can I assume that every email I get where user_2_address is not in the ccRecipients and toRecipients lists - that email was BCCed to user_2_address?
Thanks!
The bcc field in a Message is an envelope (P1) recipient only so you should always expect that it will be blank (no matter the context inside a tenant really make no difference). Like the other post referenced if it wasn't blank it would break the RFC and the purpose of a BCC, the only exception is the sent item (which is just a copy of the sent message)
No there are many scenarios that would break that particular logic eg forwarded email is one the comes to mind. You could certainly refine you result set that way, one thing you might want to examine is the X-MS-Exchange-Organization-Recipient-P2-Type: mail header that should get set in your internal to internal scenario (you need to look at the PidTagTransportMessageHeaders extended property to see it)
Goal: I'd like to be able to filter the "List Messages" API to only return emails that are sent to the user rather than any messages that exist anywhere (such as ones sent out by the user).
Right now, if you query this particular API, you get a list of all of the messages in all folders (including Deleted Items and Clutter folders).
I know that I can filter on isDraft eq false to remove the drafts - but I don't know if there's any filter to say don't include messages sent by the user.
What I've Tried: I've looked over the examples and didn't see anything about filtering like this. I've also taken a look at the OData Query Params and dug into the filter param. The problem is I'm not quite sure what I could even filter on. I do see that there is a sender parameter - but given I've connected via OAuth and haven't asked users to provide their email address I'm not sure I have an easy way to filter on that.
Theoretically, I could first do a request to the https://graph.microsoft.com/beta/me/ endpoint to get the userPrincipalName and then add a filter on from/emailAddress/address ne '<userPrincipalName>' when I call the /me/messages endpoint - but that's going to double the number of API calls I'd need to make. Is that the only option I have or is there a better way to go about this?
Thanks for your time :)
There is no filter parameter that will achieve this directly. If you want to filter away sent messages - you'll need to either decode the base64 encoded JWT access token and extract the userPrincipalName or make a call to the /me endpoint and retrieve the userPrincipalName from that. Once you have that, you can add a filter of from/emailAddress/address ne '<userPrincipalName>'.
Please note that if you are filtering on many things and you have an "order by" param that you'll need to include that param in your filter or you'll receive an error about too many filters.
I'm trying to send an email to multiple people(multiple to addresses) and have them all listed in the email clients like a regular email. When I set the header_to field on all recipients to email1#foo.com, email2#foo.com I end up with emails that have a to header set to "First Name" <email1#foo.com, email2#foo.com> which is incorrect.
This shows up as a single person with multiple email addresses in most clients and the header is wrong.
Why is the sparkpost transmission api messing with the header_to field? It's docs say that it uses this in place of generating a To header for you.
After going through every page of docs I could find to try and figure out how sparkpost's backend works I've found that you must omit the Name field on all recipients.
https://developers.sparkpost.com/api/recipient-lists/#header-recipient-object
I am having a similar problem to the one described in this previously asked question, but I am looking for a bit more detail in the answer as my lack of experience in this area doesn't allow me to fill in some of the blanks:
Tag Outlook MailItem with ID number before send without causing TNEF (RTF) send
Like the asker of that question, I would like to set a User Property, say it's named "XXXX", to a MailItem while the user is composing it, so that when the user later revisits that same MailItem in his or her Sent Items folder I could read the "XXXX" property's value again.
My additional questions would be as follows:
Dmitry Streblechenko suggests using MailItem.PropertyAccessor.SetProperty, but wherever I see that used I see people using a schema link to represent the property. What would be the correct schema link to use if I want my property still to be known as "XXXX"? In other words, what would be the correct syntax to use in Dmitry's suggestion?
I gather I could use a ".GetProperty" call to read the property later from the Sent Items, but the problem is that our add-in has been around for years, and users sent items are already full of MailItems with the original UserProperty "XXXX" in them. Will I still be able to use UserProperties to get property "XXXX" even if I use .PropertyAccessor.SetProperty to set them?
Alternatively, if I kept using the original code to set UserProperties while composing the message, but I then used .PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/id/{00062008-0000-0000-C000-000000000046}/8582000B", false) during the ItemSend, like the original poster is suggesting, then I understand the UserProperties are not sent out with the message, which is fine by me, but will they still be available when revisiting the message in the Sent Items folder? Eugene Astafiev suggests that it's safe to use that .SetProperty call, but he doesn't clarify whether it affects what happens to the message at the Sender's end.
My personal preference would be a solution that would a) allow me to send the item without having to force Outlook in any way to send the message in any particular format and b) be able to continue to access the properties in the users' inboxes as we always have through the MailItem's UserProperties, but I am aware that I may be asking for something impossible here.
You need a property in the PS_INTERNET_HEADERS namespace. E.g. http://schemas.microsoft.com/mapi/string/{00020386-0000-0000-C000-000000000046}/x-my-prop.
Yes if you specify the full DASL name.
Yes, the user property will still be there in the Sent Items folder.
I want to filter out generic, marketing based emails ("role based emails", e.g. orders#example.com, newsletter#example.com).
The Rapportive Chrome extension seems to label role based emails pretty accurately. Not only does it get the ultra generic emails, but it classifies correctly non-common role based emails like slashdot#slashdot.org, nytdirect#nytimes.com, etc.
I'm looking for either A) a comprehensive list of role based email addresses or 2) an algorithm to determine whether an email is a role based email (is there a header I should be looking at?).
Found my answer: most reputable mail list servers are including the List-Unsubscribe header in the email message.