gmail username syntax method for spam prevention - gmail

i'm very aware that this is probably not a stackoverflow question, but i figure someone here might know the answer...
a few months back i was sent an image detailing a neat method for spam prevention using a little known feature of gmail..
basically you can use a specific syntax in your email address when you give it out to include some kind of identifier within the email address so you can later distinguish which version of your email address was distributed/crawled to create spam and then, if you want, create filters based on this identifier.
something along the lines of username|identifier#gmail.com which will still beforewarded to username#gmail.com except | is not the correct token and i can't find the doco where i found this information or remember what the correct special character is.
so if anyone knows about the feature i'm describing, i'd love to find out how to get it to work!
thanks, and sorry for the non-programming question.
p.

Use a + sign instead of the |

Related

Gmail markup for online event

While there is good documentation around sending markup emails for specifying offline event. Refrence Can someone help me out on how to add handle an online event?
The issue with offline event is that I need to enter a proper postal address, however in our case the location is simply a url.
Things I have already tried
Putting type of location as VirtualLocation, but that gives error
Entering empty strings in PostalAddress fields
Marking eventAttendanceMode as https://schema.org/OnlineEventAttendanceMode, it gives error
Does gmail support markups for online events? Common sense says it should.
As said by #kayes-fahim comment you can find more information on their blog, and documentation.
By the blog post you could use the virtualLocation but you also need to set the eventAttendanceMode to OnlineEventAttendanceMode. Reference

What does the error msg ENVELOPE_HAS_DUPLICATE_RECIPIENTS mean?

Looking at the envelope JSON there is only one recipient email. So this must indicate some other issue. Can someone steer me toward something in the docs that talks about it?
Thanks
I suggest that you use the API Logging feature to see exactly what DocuSign is receiving from your application.
If that doesn't help you solve the problem then edit your question to add the logger's output.
Use a tool such as JSON Pretty print to format your API request.
You'll also need to add 4 spaces per line so StackOverflow recognizes it as software/JSON for proper display.
The answer is it means the request JSON has duplicate RECIPIENTS arrays. It doesn't mean, at least in this case, there is a problem with recipient data.
And as far as a list of error codes there simply isn't one yet.
In this particular instance my code assembling the request incorrectly wrote the recipients array. A better message would be MALFOMED_JSON_REQUEST or such since that's what the problem actually was. Once I stopped looking at the recipients data I realized the problem.

What coding is used in this string?

My app is downloading eMails from a POP3 server. But it receives "strange" subject lines. I see there is a pattern of coding in there. But what exactly is that coding? What do I google for if I want cover the parsing of lines like that?
=?utf-8?Q?HMS=20will=20no=20longer=20provide=20Netbiter=20SIM=2Dcards?=
The eMail header is:
Subject: =?utf-8?Q?HMS=20will=20no=20longer=20provide=20Netbiter=20SIM=2Dcards?=
So I know it's coded by the sender. Also this is just one of many header lines, which all seem to be valid. The subject is obviously HMS will no longer provide Netbiter SIM-cards after you replace "=20" with spaces and all the other stuff. The eMail is just a notification from a supplier.
**Found it myself:** [RFC 2047][1]
I don't remember exactly but i have experienced a issue like this before. If the subject is greater than some length of character (which i think is 75 chars) then subject will not be parsed properly.
This used to be a problem in codeIgniter (I don't use it now, so don't know the current status of this issue)
To resolve this issue you might have to change your email config.
There might be other reasons for this issue but i think this is because you have more characters in your subject.

Removing ids from url [duplicate]

Hey guys! Working on a new Cake app and wondering if there is anyway for me to remove the ID-in-URL routing from Cake. Perhaps by passing the ID in POST somehow? Having the ID passed in as a URL param just seems really shoddy and unsafe. Thanks!
"Shoddy"? It's standard practice and a perfectly fine solution to have ids in the URL. Look at the URL of your question:
http://stackoverflow.com/questions/4638262/removing-id-from-cakephp-url
^^^^^^^
id
Also, there's absolutely nothing unsafe about showing an id in a URL. It's just a number that doesn't mean anything. If a user can do something "bad" only by knowing this id, your app is broken and insecure, not the id-passing mechanism.
Trying to work around this scheme means working around the fundamental principle of the HTML protocol and opens up a whole new can of worms.
Some people prefer using slugs instead of primary key ids. This is the removing-id-from-cakephp-url part of the URL from this page. Take a look at the SluggableBehavior.
However, slugs can change. Hence, having the primary key in your URL is useful if you want to have a permalink. StackOverflow does both so that it can support both permalinking from other sites, as well as for SEO reasons. :)
Regarding security issues, I guess the other answers have already pointed out that there are other ways to make your application secure.
Why do you care? URL-s are optimized for SEO reasons, an ID won't matter if it's ain't too long. If the latter, consider using a shorter one with numbers and letters in them instead, it will be as difficult to guess as a long one with just numbers.
If you are not using GET and you do not supply the params in the URL, your users won't be able to copy-paste the location.

X-Message-Delivery in Hotmail Messages

Recently I stared deciphering the hotmail inbox/junk folder placement. After long searching I found out that Hotmail/Outlook is using their X-Message-Delivery tag they input in each mail, to determine alot of things. If you go to source of an e-mail you can see an X-Message-Delivery similar to this :
Vj0xLjE7dXM9MDtsPTE7YT0wO0Q9MjtHRD0yO1NDTD00
which if you BASE64-Decode it you get
V=1.1;us=0;l=1;a=0;D=2;GD=2;SCL=4
Based upon my research, I found out that following things are causing a message to go to the junk folder,
If "D=x" is higher then 1
If "GD=x" is higher then 1
If "SCL=x" is higher then 0
Other then that I found out that V=1.1 is allways the same and does not change in any e-mail I received (or atleast the ones I checked)
I think that "a=x" is meaning if the sender is in the receivers adressbook, or is atleast known by the receiver. If its 0 its a new sender, and therefor more likely to go to the junk folder, if its a=1 it helps to get into inbox.
I think the l=1 or l=0 has something to with, if images are blocked or not for this sender upon an open. Although I did not find this very consistent.
Does any of you know, what these tags stand for?
D=
GD=
us=
If you do, do you also know what they would change from 0 to 1 or 2 ?
Thank u!
mime-version
SCL refers to Spam Confidence Level (SCL)
SCL ratings of 2, 3, 4, 7, and 8 are not used by the service. An SCL
rating of 5 or 6 is considered suspected spam, which is less certain
to be spam than an SCL rating of 9, which is considered certain spam.
Different actions for spam and high confidence spam can be configured
via your content filter policies in the Exchange admin center. For
more information, see Configure Content Filter Policies. You can also
set the SCL rating for messages that match specific conditions by
using Transport rules, as described in Create a transport rule to
identify mail as spam or not spam by setting the spam confidence level
(SCL).
http://technet.microsoft.com/en-us/library/dn798345(v=exchg.150).aspx
http://technet.microsoft.com/en-us/library/jj200686(v=exchg.150).aspx
GD.. after an exhaustive search.. I believe that it refers to the GD2, the graphics library associated with PHP but I have no references to substantiate that. Or, I found an obscure mention of a term referred to as 'guarantee delivery' but it was a very subtle mention and I could not found any further reference to it. However, it does make sense possibly..
Email senders that have given Hotmail a reach around and gotten special treatment as being flagged 'not spam no matter what.. guarantee delivery'. Seems reasonable..
The only reference I could find in any RFCs for GD was RFC6035 Which defines GD as GapDuration
"GD" EQUAL (1*7DIGIT) ;0-3,600,000 -- milliseconds
BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16
GDuration gd = (GDuration) table.get(context);
http://media.proquest.com/media/pq/classic/doc/1397920421/fmt/ai/rep/NPDF?_s=PRwJ1WMP1Dw7%2F7ZDFW5hXUNyfPo%3D
but I don't really think they're related.
I doubt that it means Generate-Delivery-Report as Manuel guessed. Reason being, Generate-Delivery-Report is already a defined header field so it's not necessary to create another field.
The X- headers are defined originally in RFC822 Section 4
By the time I gave up on my search of GD I quit.
Whatever they mean, I'm betting that whatever they may have meant has been forgotten so long ago that probably no body at Hotmail even knows what it means anymore and even more unlikely that there will be any actionable methods for you to change whatever they are. I'm kinda still in shock that I couldn't find ANYTHING.. I'm usually really awesome at researching and digging up obscure data. ;p
Further Resources:
RFC2076 : Common Internet Message Headers
RFC2045 : Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
RFC4021 : Registration of Mail and MIME Header Fields
BCP178
The following parameters from "X-Message-Delivery" header field:
V=1.1;us=0;l=0;a=0;D=2;GD=2;SCL=4
do not affect email deliverability to INBOX, they are not neither causing this and do not indicate it at all.
After fighting with Microsoft online/delisting support the message with the same scores now go to INBOX instead of JUNK
There is unclear "something else" from Microsoft what decides whether to put it in Junk or Inbox.
This is what I wanted to mention above

Resources