mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 21:15:56 +03:00
[GH-ISSUE #157] when forward email attached files are not present #126
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#126
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ornais on GitHub (Dec 1, 2016).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/157
Originally assigned to: @jasonmunro on GitHub.
When I forward an email with attached files, the attached files are not attached.
@jasonmunro commented on GitHub (Dec 20, 2016):
Support for this has been pushed. When forwarding a message the original message is attached as a message/rfc822 attachment. This is any easy way to support any nested or complicated mime structure. It is "all or none" however, forwarding includes the complete original message, you can't delete/select which attachments to forward (you can delete the entire original message from the compose page just like any other attachment). The message part being read is still "forward quoted" and editable as the body of the forwarded message.
@dumblob commented on GitHub (Dec 20, 2016):
This is really pleasant new, thank you @jasonmunro . I'm though asking me, whether support for deleting/selecting particular attachments is on your radar (somewhen in the future) or whether you consider it not being necessary?
If I can remember, I always "filter" the attachments when I'm forwarding an email and thus the "all or none" functionality is not of much use for me. How about you and others?
@jasonmunro commented on GitHub (Dec 20, 2016):
@dumblob personally, I almost never forward a message, and usually if I do, I don't want the attachments to go with it :). It should be possible to build on this to filter out attachments, then only forward those. At that point we can create a user option to toggle forwarding the entire message or just the attachments
@BugsRUs commented on GitHub (Jan 8, 2017):
Thanks for Cypht Jason, Finally a true multi-account web client project.
I interpreted the OP's comment to mean that items attached to the original mail he is forwarding are being filtered... as in the message is forwarded without the attachments it originally had.
Not exactly my current issue. Currently I'm not able to send any mails of my own with attachments. Mails with no attachments no problem.
Is sending mails with attachments broken in general, or something specific to my installation?
SMTP server under test is a timewarnercable ISP mail account using imap on port 143. Incidentally, TWC mail does not currently support SSL/TLS.... really TWC?.... I'm using local database for all options which it is applicable.
Ubuntu-Server 16.04.3
lighttpd/1.4.35 (ssl)
PHP 7.0.8-0ubuntu0.16.04.3 (cli) ( NTS )
OpenSSL 1.0.2g
@jasonmunro commented on GitHub (Jan 10, 2017):
Hi @BugsRUs,
Thanks for checking out the project, and for your feedback. Sending with attachments should not be broken. The OP was talking about the fact that when you forward a message, it's attachments are not forwarded. There was no code to support this at the time. Your problem is different. Can you explain a bit more about where it fails? Can you upload an attachment? When you send the message, does Cypht show any errors or does it say it was sent successfully?
Can you try this patch: https://gist.github.com/jasonmunro/cbfbd79b399428427aba2a7a7078259f. In debug mode, and send a message with a small attachment. (you must be running in Cypht debug mode or the logs won't get written). Your PHP log should then capture the SMTP conversation and might give us a clue as to what the problem is.
Thanks!
@BugsRUs commented on GitHub (Jan 12, 2017):
Thanks Jason,
The patch does give more info in the log... but nothing appears out of place. I can see the SMTP instance where the message with attachment is sent. The User Interface indicates the message is sent. No errors. But the mail simply never shows up in the destination inbox, (Nor in the account's own when using the copy/self option).
This seems to be isolated to the TWC account. I added a second IMAP/SMTP pair of servers for a yahoo mail account. Attachments work with servers on that account. Mails with attachments sent via TWC SMTP server vanish into the ether with no errors I can find. Mails with attachments sent via Yahoo SMTP server to be received at the TWC account never arrive there (though a copy does show in the Yahoo inbox with the copy/self option). So seems TWC account is affected at both the SMTP and IMAP server.
The TWC account handles attachments fine when using it's own web client to send them. It receives them fine when sent from other clients. I'll look to see if the TWC account has any server settings that might be relevant.
@dumblob commented on GitHub (Jan 12, 2017):
@BugsRUs did you try other clients like Thunderbird? If they work, we could log their behavior and compare. If not, then we should probably ask TWC if they have any sort of policy (like restrictions upon certain domains/countries/whatewer) as this seems really strange.
@jasonmunro commented on GitHub (Jan 23, 2017):
@BugsRUs I just did some cleanup of the SMTP sending code, and noticed a similar problem with Bluehost that you are seeing with TWC. I found a few things that seemed to have fixed the problem (specifically, a missing MIME boundary at the end of the message, and a potentially incorrect boundary format). If you could pull the latest and retest that would be great. Thanks!