When adding 'List-Unsubscribe' email headers, what kind of handling is required on the server-side for the callbacks?
It's possible to add both a mailto-link and a web-link to the header, in PHPMailer it could look like this:
$email->AddCustomHeader("List-Unsubscribe: <mailto:unsubscribe#example.com?subject=Unsubscribe>, <http://example.com/unsubscribe.php?unsubscribeid=$id>");
But does the mailto-address have to somehow automatically handle the unsubscription, or is it okay if the request just goes to an inbox that is frequently checked by a list administrator who manually processes the unsubscribe-requests?
And what about the web-link? Does it have to point to a script that will unsubscribe the recipient there and then, or can it just point to the webpage with an unsubscribe form?
You can handle this how you like, however, you should also be aware of the List-Unsubscribe-Post header (defined in RFC8058) too, as it makes you far less prone to accidental unsubscribes caused by mail scanners.
I'd really recommend processing these automatically. It's not that difficult. The URLs in list-unsubscribe should be entirely self-contained, that is, you should embed all the data you need (for example a hash of a unique user identifier, and a mailing list ID) into the URLs, so for HTTP you might use:
'<https://www.example.com/listunsub/' . $userid .'/' . $listid . '>'
You could configure a rewrite in your web server to map that URL pattern to appropriate vars in your PHP script and do the necessary database operations to remove them from the mailing list.
For email it's a bit different:
'<mailto:listunsub-' . userid . '-' . $listid . '#example.com .'>'
For this last format you would configure your mail server to spot the 'listunsub-' prefix and use that to pipe the message into a script which could extract the user and list IDs. Notice that you don't need a subject or a message body - the address itself contains all you need, and that means that a receiver doesn't have to write a message - their mail client can simply send an empty message to the address and you will have enough info to work with.
Related
I'm writing a client-side application which should read in a file, transform its content and then export the result. To do this, I decided on Re-Frame.
Now, I'm just starting to wrap my head around Re-Frame and cloujurescipt itself and got the following thing to work:
Somewhere in my view functions, I send this whenever a new file gets selected via a simple HTML input.
[:input {:class "file-input" :type "file"
:on-change #(re-frame/dispatch
[::events/file-name-change (-> % .-target .-value)])}]
What I get is something like C:\fakepath\file-name.txt, with fakepath actually being part of it.
My event handler currently only splits the name and saves the file name to which my input above is subscribed to display the selected file.
(re-frame/reg-event-db
::file-name-change
(fn [db [_ new-name]]
(assoc db :file-name (last (split new-name #"\\")))))
Additionally I want to read in the file to later process it locally. Assuming I'd just change my on-change action and the event handler to do this instead, how would I do it?
I've searched for a while but found next to nothing. The only things that came up where other frameworks and such, but I don't want to introduce a new dependency for each and every new problem.
I'm assuming you want to do everything in the client using HTML5 APIs (eg. no actual upload to a server).
This guide from MDN may come handy: https://developer.mozilla.org/en-US/docs/Web/API/File/Using_files_from_web_applications
It seems you can subscribe to the event triggered when the user selects the file(s), then you can obtain a list of said files, and inspect the files contents through the File API: https://developer.mozilla.org/en-US/docs/Web/API/File
In your case, you'll need to save a reference to the FileList object from the event somewhere, and re-use it later.
I am using poplib in Python 3.3 to fetch emails from a gmail account and everything is working well, except that the mails are not marked as read after retrieving them with the retr() method, despite the fact that the documentation says "Retrieve whole message number which, and set its seen flag."
Here is the code:
pop = poplib.POP3_SSL("pop.gmail.com", "995")
pop.user("recent:mymail#gmail.com")
pop.pass_("mypassword")
numMessages = len(pop.list()[1])
for i in range(numMessages):
for j in pop.retr(i+1)[1]:
print(j)
pop.quit()
Am I doing something wrong or does the documentation lie? (or, did I just misinterpret it?)
The POP protocol has no concept of "read" or "unread" messages; the LIST command simply shows all existing messages. You may want to use another protocol, like IMAP, if the server supports it.
You could delete messages after successful retrieval, using the DELE command. Only after a successful QUIT command will the server actually delete them.
I use yapps to generate a parser for a LaTex-ish language (for example to translate stuff like \begin{itemize} to the corresponding <ul>-Tags) within pyramid. One command (i.e. \ref{SOMEID}) should construct a route via a call of route_url (or route_path) and pass the id to it. Since this call happens deep in the code that was generated by yapps and the grammar that I defined, I don't see any possibility to pass a request object to it.
Is there some sort of global request object? Or, since I foresee that I shouldn't use it, is there a possibility to construct a route (that depends on a parameter) without a request object?
route_url requires both a request and a registry (request.registry). It generates urls relative to the request, and it accesses the list of all routes and other settings from the registry. Thus, you must generate a dummy request with parameters you care about. For example:
from pyramid.request import Request
request = Request.blank('/', base_url='https://example.com/prefix')
request.registry = config.registry
Now you can store this request anywhere, it's good to go representing everything about your site: the hostname/port (example.com:443), the prefix your app is mounted at (/prefix), the uri scheme (https).
If you need to get this deep down into your code you may have to make it a global or attach it to some context/registry that you have available, but what I've shown is how to make the request that you require.
I'm accessing GMail via IMAP using OAuth2 authentication and Zend_Mail_Protocol_Imap.
It all works great.
What I need to do is present emails in thread form just like the GMail interface. Google make this really easy because they have an X-GM-THRID header that links a conversation with a 64-bit unsigned integer.
My problem is: when presented with a single email, how do I find out what X-GM-THRID it belongs to?
First off Google says that there is a server extension X-GM-EXT-1 which is active. You can check it is there using the CAPABILITY command (and I have).
All the information suggests that if this is active then the X-GM-THRID will simply be returned as a header, but it isn't.
Perhaps I need to ask Google to return it via the fetch command. Google does describe a simple fetch process here:
https://developers.google.com/google-apps/gmail/imap_extensions
My code is sending TAG5 FETCH 3673 (FLAGS RFC822.HEADER X-GM-THRID) but the headers do not include an entry for X-GM-THRID.
I've even simplified it to TAG6 FETCH 3673 (X-GM-THRID) to be exactly as described in the google example. In this case no headers are returned.
I'm not massively familiar with IMAP commands and I'm not sure if Zend_Mail_Protocol_Imap is abstracting some handling which means this header is being removed.
But I do know that this is driving me mad.
Am I missing something? Is it not a header?
Okay, so it looks like it is not a header. It is an attribute in the IMAP command and response.
The standard fetch command sent by Zend_Mail_Protocol_Imap is "TAG5 FETCH 3673 (FLAGS RFC822.HEADER)"
The code that handles the response only expects to be dealing with 'FLAGS' and 'RFC822.HEADER'. It passes this information to a Zend_Mail_Message object which extends Zend_Mail_Part.
Zend_Mail_Part parses information about flag. It also parses the header.
The additional 'X-GM-THRID' attribute that I added does actually get a response. but since it is not passed back to Zend_Mail_Message there is no way for me to use it. It gets lost in the ether (at around line 171 of Zend_Mail_Storage_Imap in my Zend Library to be exact).
So I've hacked the core... Zend_Mail_Storage_Imap::getMessage now expects $data['X-GM-THRID'] and passes it to the constructor Zend_Mail_Part. And I now have a method Zend_Mail_Part::getXGmThrid which solves all my problems. I'll obviously refactor them into my own classes extending Zend_Mail_Storage_Imap and Zend_Mail_Part in the not too distant... but for now I know this works.
I'm struggling to find documentation that gives a clear example of how to enter a message in the rmail application.
I need to specify who the email is from, the subject of the email, and then follow that with some content. It's for a small school assignment where we are relaying "status updates" from imaginary machines on an imaginary factory floor.
This is the closest I've found, but it is not very clear: http://www.s-gms.ms.edus.si/cgi-bin/man-cgi?rmail+1
Can anyone give me an example of how I would send a message that looked like this? (obviously not including the comments...)
/* header stuff */
From: something#something.com
Subject: Status update for machine 5
/* message content */
Machine ID: 7
Status Reported: Machine going offline (status 6)
Status effective: 2012-06-02 12:30:23
I am opening rmail via software controlled pipe in my application without problems, I'm just not sure how to format the data I am feeding to it since I can't find any examples online.
Thanks!
You are probably interested in using /usr/bin/mail on most modern Unixes, not rmail.
You should read the man page, but generally, it would be sufficient to use the "-s" flag to set the subject of the mail, and input the content of the message on stdin. There is no need to set the From: line, as the system will do that for you (and in the general case, the system will not let you specify arbitrary from addresses to prevent forgeries.)