Possible Bug in Mail.app

I am running a server and clients -- all at 10.4.4. The mail app on the clients Version 2.0.5 (746/746.2).
I have been tracking down errors in my imapd log file. The errors are:
Feb 5 00:18:05 EaseServer imap[23046]: IOERROR: reading message: unexpected end of file
You can find various people asking for help on this but no help. I believe I tracked this down. It is not an imapd problem but a Mail client problem.
When the client wants to add a file to an existing mail box on the server, it does an APPEND command. The "literal" at the end of the command can take on two forms: { number } or { number + }. The second is called the "non-sychronizing" form.
By default, this is supprted by imapd (and advertised) and used by the client. In this case, the client is suppose to not wait for the server to reply with the "go ahead" response but just blast the message across the wire. Well... it does not. Instead, you get a pregnant pause and eventually imapd times out and rejects the request. The client, eventually, may even crash from all this but, for sure, it will provide a very poor user experience.
The work around I did was to download CyrusIMAP from the OpenDarwin.org. In cyrus_imap/imap/version.h, the CAPABILITY_STRING advertises LITERAL+. If that is removed, then imapd does not claim to support it (even though the bug is in the client). This prompts the client not to use it. And things appear to work much better.
I know virtually zilch about IMAP protocol, cyrus, Mail.app, or imapd -- so, someone needs to verify all this.
The thing that is curious to me is why I hit the problem and others seem to be working fine. There are a few people that have noticed the problem but, they seem to be the exception and not the rule...

I have tracked down my problems to a call to sasl_decode in prot_fill (in imapd).
To recap: I am getting IOERROR: unexpected end of file in my imapd log file. The client interface is also slow and sometimes crashes.
It turns out that if the client has Kerberos GSSAI authentication and the client tries to do an "APPEND" command (which is what the imap protocol uses to add a message to an existing mailbox), the APPEND frequently fails (but not always). The rest of my Kerberos stuff appears to be fine.
The APPEND is sent across to the server. The client can be set up to do LITERAL+ or not. The client sends all of the message in either case. The server reads all of the packets. Usually the first packets go through the sasl_decode and result in valid text. But after the first block (4096) or so of data, the remaining data is lost and sasl_decode reports back that there is only two valid characters. No errors are reported back (that I am aware of).
I ended my quest at this point last night and I probably will not pick it up again. For now, I can work around the problem by switching to plain authentication and just set up a VPN before using mail.
I hope this helps whoever follows in my footsteps...
Perry

Similar Messages

  • Possible bug in mail app after updating to 2.2

    Just updated and found out that I can't email anything out. I get "The sender address was invalid" message. Tried deleting and re-adding email account but no luck there. I use gmail if that's of any help. Anyone else got this issue?

    Unfortunately (or perhaps fortunately), I don't think it's a bug.
    It looks to me like Rogers/Fido up here in Canada seems to be blocking (intentionally or not) gmail's SMTP server. It was out almost all day yesterday, then starting working around 4 for some people, then is back down this morning.
    I could be wrong, but that's the theory where I've been talking to people at google groups and howardforums, as it seems to work on WiFi for most people.
    Some people have switched their primary SMTP to the built in rogers one, but I have too many trust issues for that
    Hopefully Rogers gets their act together sometime soon.

  • Is anyone experiencing a bug in mail app in iOS 7 ?

    I'm experiencing a bug in mail app in iPhone as well as in my iPad... This bug makes all my mails unread whenever I refresh for mails and whenever I read a new mail it stays unread even if a close the app. Please help me if possible...

    I've not heard of or experience any such issue.
    Have you tried removing and readding the accounts in question?

  • Is it possible to get Mail.app back?

    Hi
    I have a Macbook Pro 13'' with Mountain Lion.
    Since I bought it I have only used Outlook as a mail program and subsequently, I deleted mail.app with the use of CleanMyMac, since I'm on a 128gb ssd and I wanted to free up as much space as possible.
    However, now I want to get mail.app and cal.app back because of recent problems with Outlook, but I can't seem to find any downloads.
    Unfortunately, I can't re-install the whole OSX. So I'm looking for a solution were I can get Mail and Calender back without re-installing the OSX?
    Is there anyone in the fora or at Apple HQ that can help?
    And BTW, I've search the fora, only solutions involving snow leopard is available.
    Thanks for putting in the effort to help me!

    The ONLY way to reinstall Apple OS X pre-installed apps such as Mail and Calenedar is to use OS X Recovery
    The Mail app itself is only 54MB and Calendar 47MB.
    These apps are not available for individual download anywhere on the internet.
    You can't reinstall OS X?
    That's a huge problem if you ever need to repair the startup disk. That requires OS X Recovery utilities.
    Can you get to an Apple Strore? If so, they may be able to help you restore OS X which reinstalls the apps for you.
    Apple Store locations >  Apple Retail Store - Store List

  • Bug in Mail App in LION

    Just the other day, my hard drive depleted to the point of 54MB and I got a warning that my start up disk is full and I need to delete files. I found that strange since I have about 200+Gig available, the last I checked and did not do any new downloads.  But I deleted a bunch of stuff anyway, and restored my size to 9 Gig. 
    Next day, same message. I knew something is wrong, called Apple and discovered that there is a bug in the Mail app.  For some reason it created a Recovered folder in the Mail folder that just kept copying over and over again.  The tech told me it's a bug but no clear direction on how to solve it and/or when.  The only thing we did was delete that file and my space was restored.  I was told that is all I would need to do for now and I should be fine.  Well, today, again my HD is depleting and sure enough, there is that recovered folder again.
    Anyone else with this problem?  Specifically, it appears to be doing it with my Yahoo mail.  I'm thinking I should delete the account, start over.  If anyone has other ideas or if it's a settings thing in Mail  or Yahoo pop settings, please let me know.
    Thanks

    It's not related to a third party app. I don't have any.  The tech was able to pinpoint the folder in the Library/Mail/V2/Mailboxes
    He said they have had reports of this bug and he went directly there. So they must be aware of it.

  • Bug in Mail.app preventing from retrieving mail

    Found a bug today when using Mail.app:
    What happened:
    - I setup my IMAP account onto Mail
    - Synchronized Mail with my IMAP account by clicking 'Get Mail'
    -> I could get all my mails, but any other click on 'Get Mail' ended up with doing nothing. Even the 'Check for new mail every x minute' checked, I was never getting new mails. The only way to retrieve my mails was to quit Mail.app and run it again or Go offline in the App and then click 'Get Mail'
    Did some investigations and here's what I found:
    - Displayed the Activity Viewer at startup
    - I saw that the app was connecting to the server, then getting mail, then doing some caching over my attachments in existing mails. While the task running on attachment was not finished I was able to click 'Get Mail' and see a task for it.
    - Once the task for attachment was finished, 'Get Mail' stopped working and no new task appeared in the activity viewer each time I clicked the button
    - Quit Mail.app and ran it through terminal.
    - When caching the attachments, I saw an exception about an absurd size in one of the attachments and some lock issues (sorry didn't copy the exception at that time)
    - Sorted my mail by attachment and looked for a mail for an attachment with a strange size.
    - While I did not saw anything weird in the sizes, when I went over one of the mails, got again the exception in the terminal.
    - Deleted the mail, restarted Mail.app
    -> And everything started working fine
    Conclusion:
    - Either a bug in the Mail.app code or a faulty attachment can create a lock between threads, preventing then a normal functioning of the application... (sorry I did not kept the attachment)

    It's not related to a third party app. I don't have any.  The tech was able to pinpoint the folder in the Library/Mail/V2/Mailboxes
    He said they have had reports of this bug and he went directly there. So they must be aware of it.

  • Bug in decoding of From-addresses in Mail.app

    Dear all,
    since quite some time there is a bug in Mail.app, which leads to problems in replying to certain mails. The bug is similar (or the same) as in thunderbird 2 (see https://bugzilla.mozilla.org/show_bug.cgi?id=254519), which was fixed in Thunderbird 3.
    If a "From:" line encoded with RFC 2047 contains characters which should, per RFC (2)822, be quoted (because it contains commas (",") or similar) Mail.app does not decode it properly but treats (in the case of a comma ",") this as two different addresses. A reply to such a message usually results in a bounce or error (since the first part is usually not a valid address).
    An example for such a "From:" line is:
    From: =?iso-8859-1?Q?M=FCller=2C_Henry?= <[email protected]>
    This is correctly encoded and thunderbird 3 and (I hate to say this) outlook treats this correct.
    Maybe someone from apple reads this and there is a chance to get this fixed soon, since it is rather annoying and causes a lot of user questions to our helpdesk. Or is there another easy fix (without changing the "From:" address.
    Best regards,
    Damian

    Apple doesn't work here (except to moderate posts for terms of use). We're all just users like you.
    If you want to file a bug report, sign up for a free Developer account and file one here: http://developer.apple.com/bugreporter/
    Or, use the Provide Mail Feedback menu item in the Mail menu.

  • Quoting/threading phenomena in mail.app -- due to problems in incoming messages?

    Folks:
    Mail 5.1 on MacOS 10.7.x
    I began using Mail.app when I installed 10.7, shortly after the initial release.
    No problems with respect to unformatted email or replying to short, trivial length formatted message.  For complex, on-going discussions  I feel that consistent and reliable quoting and threading behavior are essential.   But that is not happening in some cases. I'd like to figure out why, and what I might do to fix the issue.
    (Note:  I do not want to get into a discussion here of formatted versus unformatted email.  Both have their pros and cons. Nor do I want to spend a lot of time debating this issue with my correspondents.  As a matter of courtesy, I set Mail.app to respond using the same message format as the original message.)
    When I reply to a formatted email,  I notice that mail.app sometimes draws a dark grey box --with rounded corners-- around one or more incoming paragraphs, placing a circled "X"  "close icon" at the upper left.   I don't get it.  To what does this correspond?  Why does mail.app mark-off this text and offer a "close icon"?   As far as I know I'm not doing anything that implies I might want to delete the text.
    (Note:  Rummaging around in the corresponding message source, it seems that these boxes correspond to blockquoted text in the received message.)
    Editing within one of these boxes is really unpredictable.  Sometimes I can select an insertion point and insert a line-break, in preparation of replying to the text just above.  Sometimes nothing happens. Sometimes I can select text, and cut it. Sometimes nothing happens at all to the selected text.
    Mail.app commonly doesn't  correctly increase the quoting level in such paragraphs.  Using
        Format> Quote Level>Increase
    to maintain threading history manually is fairly easy since I've defined a function-key shortcut, which works some of the time -- but  the effect of this command is unpredictable.  Sometimes this command deletes the selected text entirely.  (Grrrrrr!)  The workaround I've found is to select smaller chunks of text.  In such cases, this command generally works correctly.
    Meanwhile, messages from exactly one person --who uses gmail exclusively-- are displayed in a completely unique threaded format by mail.app.  The entire short history of 5 messages from him are displayed on multiple virtual sheets in one message window, with the latest first.    In one view, clicking on the "see more" link at the bottom of his messages unleashes a cool-looking accordion opening effect and displays my part of the thread. (I guess.  I don't totally understand this display concept.  But it looks very cool and seems to handle quoting and threading pretty well.)
    What's going on?
    My best guess is that mail.app is struggling with "inconsistencies" in the incoming messages from different people using various email clients.  I seem to recall reading that email tech specs  are a hodgepodge of evolving and contradictory  standards. Is that correct?   Is that the root of my issue? 
    Many of my correspondents are non-tekkies and/or non-affluent, and they use whatever email client they can afford.  Some could be using really old email clients.  That doesn't help, right?  Are blockquotes a really archaic formatting measure?
    When these problems occur, they can cost me a lot of time and trouble.  It's really distracting to have to deal with portions of the incoming message disappear.
    I don't think it is practical to persuade my correspondents to upgrade their email clients.  Some of them have trouble simply setting the preferences to support quoting.   Threading is a difficult concept for a few.
    Any suggestions?   Any mail.app preference settings I might try adjusting?  Any add-ins?   Is it possible to tell Mail.app "interpret all incoming blockquotes tags as simple breaks" or strip them entirely?  Or ...?
    TIA

    haavee:
    Thanks for your reply on this thread.
    And thanks for the confirmation:  Yes, often difficult, and completely unworkable in some cases. 
    To my surprise, I've been able to find very few people reporting similiar observations.  Very little about this issue at all on the web.
    I looked for command-key variations on Format --> Make Plain Text, hoping for a block action, but none I tried was any different.
    Here is my current view of the issue:
    • For formatted messages, each email client operates differently.  If there is a standard it seems to be no more robust than "use simple HTML for formatted messages".  
    • The "can't insert" issue, as well as those mysterious rectangle-surrounded blocks, seems very correlated with the presence of html <div> sections in the message.  It is awkward to experiment, so I've only done a limited amount.  My observations so far:
    -- I don't think you can insert text anywhere "inside" a <div>, and mail.app seems to treat <div> as a "sticky" attribute -- e.g/ very difficult/impossible to remove without deleting the text inside.  The copy-style method doesn't seem to affect <div> tags.
    -- Based on one case, it appears that message bodies composed of back-to-back <div> sections are impervious to inserts anywhere. (The email client used by one particular person with whom I've corresponded seems to build messages out of --you guessed it-- back-to-back <div> sections. Putting on my HTML coders hat -- I cannot see any sense at all in doing this. Smells to me like a kludge/hack, as you prefer.)
    • What about an applicable mail.app add-in?  I can find mail.app add-ins, but it seems the  mail.app tech info (API) isn't public, so those that exist are based on guesswork about how it works. This means that add-ins must be re-tooled possibly for each new version of mail.app. Altogether, not encouraging for add-in developers. And, yes, consistent with that the range of functionality I've seen is rather limited.  So, I've given up looking in the add-in category.
    • Applescript has commands for controlling mail.app generally, but I didn't see anything approaching the level of function necessary to remove <divs> by global search-and-replace. (I'm far from an Applescript expert, so it is very possible I missed something.) Nor did I see any general command such as Clean up dodgy HTML in message.  (I can dream!)
    The only bit of progress I've had is finding TextSoap: http://www.unmarked.com/textsoap/ which may have promise. But I have had no time to evaluate it and it may be a month or so before I get a chance to check it out.
    Looking at the upper right of the window in which I'm composing this message, there's a button "HTML" that lets me see --and edit-- the underlying HTML. On first glance, there's not enough functionality to, say, efficiently clean up all insert-resistant blocks in a message, but it looks practical to clean up individual blocks, and maybe that's all it would take.    Though I imagine that the user base for these forums is not very different from that of mail.app, I'm guessing adding this function to mail.app isn't even a dim possibity.  Oh, well...
    I note you are happy with your solution, so I'll try see if a variation of it might help me.
    Thanks,
    h.2

  • Sync'ing "Sent"-box between Mail.app and e-mail sent using the web-app (2)

    Hi,
    A while ago, I posted this question, and Allan Sampson provided the answer, how to do it quickly and efficiently (see below).
    However, that method turns out to have a flaw:
    Here's what I just posted to Apple's sofware feedback:
    ========
    During the week, I connect to the internet from behind a firewall that prevents IMAP usage. I therefore use the webmail access to my @mac.com account. Once I am connected from a more liberal network, I let Mail.app sync with the @mac.com account, and transfer the "sent" messages from the server (the "Sent Messages" sub-folder at the bottom of the left-hand side folder listing in Mail.app) into the "Sent" (paper glider looking) folder, to be stored locally. I store about 7 year's worth of e-mail and use it as database.
    Unfortunately, when so transfering the sent messages from the @mac.com server into the local "Sent" folder, the "Date Sent" inexplicably changes to the date of transfer, and the original date of sending is obliterated!!! This should not happen, and I cannot but consider it a bug in Mail.app.
    Please fix this ASAP!
    ========
    In the meanwhile, does anyone know of a workaroud, other than forwarding those "sent" messages to myself, whereby the original header with the original "date sent" would be retained?
    Thanks, Tristan

    Tristan, we’re getting nowhere. For some reason that escapes me, you keep ignoring, misreading and/or misunderstanding what I’m saying...
    At this point, I can only guess that you don’t really know what I’m referring to when I talk about message headers. The message headers are not the same as the column headers that Mail displays in the message list. The message headers is what Mail shows above the message body when viewing a message. You can choose the amount of header information that Mail shows there by default in Preferences > Viewing > Show header detail, and you can tell Mail to show all the headers while viewing a message by doing View > Message > Long Headers.
    There is no such thing as Date Sent or Date Received message headers. The date & time that Mail shows in the Date Sent column is the date & time that appears in the Date message header and is set by the sender’s mail client. The date & time that Mail shows in the Date Received column is the date & time that appears in the latest (topmost) Received message header and is set by the recipient’s incoming mail server.
    If the message headers that Mail uses to determine the date & time that it should display in the Date Sent and Date Received columns are missing, Mail cannot reliably show the right date & time there, but it may still try to do so by looking somewhere else, such as the Internal Date message attribute if the message is stored on an IMAP server. Problem is, contrary to what happens with the message headers I’ve mentioned, the Internal Date is an IMAP attribute that isn’t part of the message itself, and hence, is lost as soon as the message is moved out of the server...
    Before the transfer:
    <http://homepage.mac.com/thubsch/eMailTransfer0.gif>
    What you’re showing here is Date Received, not Date Sent, but I could say the same I’ve said about Date Sent in previous posts, except in this case Mail gets the date & time to be displayed there from the latest (topmost) Received message header. The thing is, that header is set by the recipient’s incoming mail server, so don’t be surprised if you don’t see it either by doing View > Message > Long Headers while viewing a sent message...
    Again, if that message header is not present, Mail will have to get the date & time to be displayed in the Date Received column from somewhere else. In particular, if the message is stored on an IMAP server, as is the case here, it can determine that date & time by querying the IMAP server for the Internal Date message attribute, just like it can for the Date Sent column when there is no Date message header.
    BTW, note that Date Received is meaningless for sent messages (Mail has absolutely no idea when the messages were received, not even whether they were actually received), but since those messages would normally have no Received message header, Mail would actually display the right sent date & time in Date Received for sent messages if the Date message header was present.
    However, I wish to store those messages on my machine locally. In answer
    to my earlier question (for which you cited the URL), the really simple
    procedure was recommended, to select all messages from "SentMessages"
    and press-and-drag them into the "Sent" folder. When I do that, the "Date
    Sent" for all those messages becomes the date & time of transfer:
    <http://homepage.mac.com/thubsch/eMailTransfer1.gif>
    And again, when you do that, Mail can no longer query the IMAP server for the Internal Date message attribute. Since the message headers that you keep ignoring and that Mail needs in order to be able to show the right date & time in the Date Sent and Date Received columns aren’t there either, Mail simply has absolutely no way of knowing what date & time should it display there other than by looking at the creation date of the *.emlx files associated with those messages...
    Now, you are welcome to write a dissertation on how come this happens and
    why this is not a bug in "Mail.app". However, you are missing the boat:
    Interestingly enough, I’ve already explained multiple times why that happens and why this is not Mail’s fault. The culprit here is the mail client used to send those messages, which fails to set the Date message header that Mail (or any other mail client, for that matter) needs in order to be able to determine what the Date Sent is supposed to be.
    It’s you who keeps missing the boat and ignoring, misreading and/or misunderstanding everything I’m saying...

  • Can I open the Mail app without configuration an email address?

    I'm trying to open a .eml file, which seems possible in the Mail app.  However, I can't open the Mail app without configuration an email account.  I don't have an email account to configure; just want to open the file.  Or, let's suppose, I just wanted to browse the interface?  How to avoid the account setup part?

    Just enter anything short & plausible in as few fields as you can get away with : '[email protected]' works here, you'll get a brief 'not responding' or such at each stage, but it does allow you to use Mail.

  • Bug report: Mail sends messages with empty bodies

    Over the last year, I have experienced a particularly irritating bug in Mail.app at least a dozen times. I finally have a good idea as to what causes it.
    The problem involves long email messages (often with attachments) that end up being sent with blank bodies (and no attachments). Even the copy in the "Sent" folder ends up blank, and several minutes or hours of work vanishes into thin air, not to be seen ever again.
    I finally realized that this bug only occurs when sending mail through our work SMTP server while outside the work firewall, and only as a result of a certain sequence of events. Here is what happens:
    When we connect to our work SMTP server from outside the local network and without going through the VPN, the SMTP server requires password authentication. If the current SMTP selection in Mail.app is the one that does not require authentication, the SMTP server rejects the message. At that point, Mail.app opens the email I am trying to send and brings up a modal dialog that says "Cannot send message using the server xxx.xxx -- The server response was: xxx@xxx relaying prohibited. You should authenticate first." The dialog also presents a drop-down list of SMTP server choices. I choose the password-authenticated version of the server and then click on "Use Selected Server" to send the message.
    This works almost all the time, but on occasion it ends up sending a blank message! If I have a long email, particularly with attachments such as PDFs that are rendered in the body of the message, it takes a few seconds for the mail message to be rendered underneath the modal dialog box. Since I am used to this STMP rejection behavior, sometimes I am too fast to choose another STMP server from the list and click on "Use Selected Server" before the mail message is rendered on screen! The result, invariably, is a blank email message that gets sent.
    I guess what is happening is that when the STMP server rejects the message and hands it back to Mail.app, the message gets copied into a buffer in order to be displayed on screen. Selecting another server and resending it immediately (before the message is copied into the buffer completely) causes the message body to get trashed.
    I hope that this description is adequate for Apple QA folks to replicate and isolate the problem (and hopefully fix it). One solution (although not the most elegant one) would be to disable the "Use Selected Server" action until the message is copied into the buffer and rendered on screen.

    This could be related to another bug reported here recently:
    E-mail looses all images if mail server doesn't accept outgoing email...
    You cannot count on Apple looking into this or even noticing it if you report it here, so I suggest you the same I suggested in the other thread, i.e. report it in one of the following places:
    http://www.apple.com/macosx/feedback/
    http://developer.apple.com/bugreporter/

  • Starting mail.app in the faded out-mode???

    I configuered my account to start mail.app faded out, but starting tiger, the main windows appears in the front. All other apps are okay.
    I remember, I had this problem in an earlier version, but an update repaired it. Waiting and waiting for an update, but nothing happens.
    Has anybody an idea, what I can change?
    Thanks
    iMac Intel 2.0   Mac OS X (10.4.3)  

    I mean "in the invisibel mode". The word fade out is wrong i think.
    in the systempreferences for the user I can define, which program should loaded at start up. If I say: start iTunes invisibel, i do not appear, it is running in the background, but I do not see anything of the app.
    Opening mail.app, the main window is visibel, it is not in the front. It is not possible to see the desktop.
    In earlier versions it was possible to let mail.app run but do not see anything of the app.
    Has anybody an idea? Thank you very much.

  • Current/frontmost outgoing message ID/object in Mail.app?

    I have tried a lot but cannot get a solution.
    1. I created a new message in mail.app
    2. I want to do something with it
    Problem: I only managed to get the front window, but not the current open outgoing message.
    I can create a new message programmytically by calling "make new outgoing message". I can also save the ID from there.
    --> But how do I get the id (or object) of the current open/frontmost message?
    Message was edited by: fabiradi

    What if the message is already created by the user (clicked button "new message" in GUI)? Is there a list of last-created outgoing messages somewhere?
    OK, that wasn't clear from your original post.
    It is possible to ask Mail.app for all outgoing messages:
    tell application "Mail"
      set newMessages to (get every outgoing message)
    end tell
    From there you can iterate through the list. The problem I see is that there's no obvious way of differentiating messages created by your script vs. messages created manually by the user. Maybe you have a plan for that.

  • Mail.app over Socks5 proxy?

    Hello : ) Does anyone know if it's possible to use Mail.app over a Socks5 proxy? How would I configure that? Thanks in advance -- Miguel

    Mozilla Thunderbird will do what you ask.
    However, I'd much rather use Apple Mail, so am anxious for any possible workarounds.

  • Sobriety check for Mail.app

    Hi everyone,
    I've been asked at work if it is possible to add this functionality to Mail.app, in a similar vein to what Gmail has recently added to their service.
    In a nutshell, what I need to create is an alert dialog that pops up when a user clicks the send button in Mail that allows them to confirm they want the message to be sent. It's not really a sobriety check (at least I hope not) but really a chance for an employee to avoid mistakes in their email message before it goes out.
    At this point I'd just like to know if it's feasible before I go down this route and if anyone has any advice for an AS noob looking to do this. Bonus points if you know whether it's possible to add a modifier to the Send button to bypass the script.
    Thanks much!

    Not directly - at least not via AppleScript.
    Mail.app supports AppleScripts for scanning incoming mail messages. There is no support for AppleScript on outgoing messages.
    It is possible to write Mail.app plugins, but they're not well documented (search for 'Mail.app plugin' for an idea) and requires an understanding of Objective-C.
    The last option I can think of is to not use Mail.app's automatic send/receive. Instead using a stay-open AppleScript to periodically get mail and check for messages in the outbox. If it finds any it posts the question then sends the message(s). The problem with this approach, though, is that it's far from foolproof (the user can send the message manually by enabling automatic mail sending).

Maybe you are looking for