Recently, I found out that whenever I am sending any special character such as "ß" or a "Ö" e.g; ÄßÖÜöüß as address, paypal is not able to process it.
Then I tried URL Encoding them & sending it to paypal, but the issue is, in Paypal Manager the address values shows as encoded one, also in cases such as like these, where I send special character for every field, such as first name, last name, address, the page shows me some weird error.
I have no idea about how to send it to paypal other than urlencoding it, So please if any one have any insight into it, that would be of great help.
Paypal only accepts UTF8 strings. You need to UTF8 encode your string if it's not already.
Related
I noticed that the following gmail addresses are equivalent: foo#gmail.com and f.oo#gmail.com, and I would like to collapse these equivalent email addresses in a single category. I searched on the Internet about the gmail collapsing rules, but I didn't find anything. Do you have any idea of how can I normalize the gmail addresses?
P.S. By equivalent I mean that if I send an email to f.oo#gmail.com, then I will receive it in my mailbox, i.e. foo#gmail.com.
P.P.S. I think that somebody asked for the same question here: What emails are equivalent to each other?, but no correct answer was given. Maybe I should close this thread?
The GMail rules work like this:
Case is ignored.
Dots are ignored.
A plus character and anything following it is ignored.
You could thus normalize GMail usernames by first lowercasing the string, then removing all dots, then truncating the string right before the first plus character.
Note that these rules are specific to GMail. (Ignoring case in usernames is fairly universal but apparently not required by the relevant standards.)
Users may be angry if you send them email at "stripped" addresses. If someone gives you the address joe+yourapp#gmail.com, that's generally because they want to be able to filter the output from your application. If you then send mail to joe#gmail.com, you're sort of going against the user's explicit wishes.
Hi i am working on an email system which is used to send email when user is registered on the site. The email when sent in plain text format is delivered correctly but it fails to get delivered even when everything goes ok with the script when sent in html format. It doesn't even work when I use aol or gmail smtp server for sending it. Does my webserver bans email from sending in html format or there's any other problem?
Not so much the server, but probably the email client.
Depending on the sort of formatting you used in the html, it's far more likely for the email to be rejected by either the email reader, or some spam filter along the way.
First try sending the email including both parts - the text part and the html part, but keep the formatting in the html part to a bare minimum. (ie start with no formatting.) Then slowly increase the formatting to see when it stops. Links for example should be completely "straight" - show the user everything in the link - the text should match the href. Buttons are not allowed.
No mater what you do, html emails will always have a higher filter rate than text ones, so carefully consider the use of html in the first place. It doesn't matter how pretty the email is if it doesn't get delivered.
I need to be able to display ads on email forwarded through a server (preferably postfix) based on the demographic information of the recipient. Basically a message will arrive for someuser#fakedomain.com and be forwarded to realuser#theirdomain.com with a small advertisement at the bottom.
I would like to use postfix because it appears to be able to use mysql data for various tasks, which would be beneficial so that the system could be controlled by a web app that feeds the database.
I'd prefer to use OpenX for the ad server due to targetting channels (used to select ads based on demographic information), the ability to do text ads as well as email zones, and the ability to run it locally. Other ad servers that are better suited to this problem are acceptable, of course.
The core of the problem, as I see it, is being able to write something at the bottom of any given email message. Of course html messages make this even trickier, but I'd settle for having a solution that works for plain text and work up from there.
Commercial software is an option as well, but a few days of intermittent searching hasn't turned anything up.
Simply writing something to the bottom of the email message will fail miserably in a LOT of cases, particularly with HTML email encapsulated in a MIME multipart message (or anything else in a MIME multipart message) because anything after the last MIME section marker is explicitly supposed to be ignored by any MIME parser. If you want your app to work it needs to
determine if the target message is a MIME message other than TEXT/PLAIN
If it is not, append your text only ad at the end and you're done
if it is, determine if its multipart
if not, then you need to determine the content type of the whole message
If the content type is HTML then you can attempt to insert your ad HTML somewhere appropriate. This will be very hit or miss since you have no idea what the HTML layout will be like.
if the content type is anything OTHER than HTML (or maybe RTF), you're best off not touching the message.
If the message is multipart, determine the subtype
if its 'mixed', then you need to determine which part if any is the primary readable content, and then modify that portion as if it were the whole message based on the above rules
If its 'alternative' then you need to find ALL the readable portions and modify each of them in turn according to the above rules
Finally, and most importantly
Be prepared for the massive ill will you will receive from everyone who gets mail routed through your server.
Let me see... People sign up for your service, which I assume is free. They provide you their real email address and in return you provide them a different email address which they can use to e.g. subscribe to mailinglists and for other services. And maybe some spamfilter functionality? That sounds like a legit service to me, especially if you only provide the ads to the person who subscribed. I do wonder if you'd get many subscriptions, though, since many people can just as easy use a Google, Yahoo or Hotmail account for these purposes. So, what is the added value those subscribers will get?
Anyway, you would need to modify existing emails, which is a bit complex when they are HTML mails or if they're digitally signed. (Especially in the latter case, you would actually block the recipient from receiving those emails, since their email system would detect that the email has been tampered with. You might also be at risk of possible legal problems, although I don't think there's anything illegal as long as the recipient agrees with the terms of your service.
Does anyone have a reason / preference as to the best format to send email responses from a website (payment confirmation / password reminder’s etc)?
Thanks
Jon
In your emails, use plaintext with links to your HTML pages. HTML in email is generally widely reviled as a bad idea, because it's a gigantic security hole.
Never send passwords in email, even as a reminder. Send a link to the user's registered email address that allows them to reset their password. The absolute fastest way to make me quit using your service is to send me my password via email in plaintext.
plain text. No html.
Formatted plain text, please. The system my office uses currently, I had nothing to do with designing it, sends customers a formatted plain text email that looks professional, loads quite quickly in email clients, and it prints just as it looks on the screen. Not only is HTML a security hole, it can really slow down the email downloading/opening process depending on how much extraneous content is included (background colors, images, etc.). In addition, plain text is almost guaranteed to print out as displayed on the screen whereas HTML can have issues.
For passwords, as McWafflestix said, don't send passwords to email addresses. One approach to addressing the forgotten password is to create a module on your website that sends users an email with a link confirming they forget and need to reset their password and then have them answer a secret question they created. Once the identity is confirmed, send them an email with the new temporary password with a link to log in--once they click the link and enter the temporary password, have the user enter a new personal password.
Gmail automatically greys text that looks like a signature. Anyone have any guesses how it does this? (I've noticed that it depends on the presence of the sender's name, but I think that's only part of the story).
I ask because I'm working on a web application that has an email interface, and I'd like to remove users' signatures before displaying the contents of their emails.
Email signatures are supposed to be started with two dashes, a space, and a newline.
See Wikipedia and RFC-3676