Google has decided that if someone sends an email to a Gmail address that is the same as yours, except for a period or few, it was meant for you; and they relay it to your mailbox.
In other words, if I have an address cilias@gmail.com (which I do not), and someone sends a message to c.ilias@gmail.com (or cil.ias or cili.as or ci.lias or cilia.s or c.i.l.i.a.s, etc.), and none of that Gmail address does not exist, the message will arrive in my cilias@gmail.com account.
All this does is increase my spam.
That’s old news.
Did you know that cilias+girlfriend [at] gmail.com also arrives in your mailbox?
One could see it as a good thing. If you need to sign up to a site which you’re unsure about you can give them the dotted version of your address – so if they try to spam u or bombard you with “newsletters” you can simply filter that particular address out.
@Reynie: this behaviour is correct cilias+ must be sent to cilias.
It is in the SMTP protocol.
The behaviour described by Chris isn’t, though.
Actually the SMTP spec (rfc 2821) makes no attempt to control what various bits of the local part of your email address mean. Here’s a quote: “the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.” See section 2.3.10. This means that only gmail.com decides what means what in the local part of the address. The fact that most email servers have come to do it the same way doesn’t mean that they all have to.
Likewise the spec for the format of an email (rfc 2822) has similar wording.
Anyway, sounds like it sucks in some cases. Can you make a filter that will throw away messages with the wrong number of periods in the local-part?
actually, the RFC says that periods are NOT allowed in the user part of an email address. Google does allow you to use this character, but ignores it when delivering mail.
You should be thanking Google for allowing you use this character at all
Mick, that’s not correct. Section 3.4.1 of the rfc says this:
addr-spec = local-part “@” domain
local-part = dot-atom / quoted-string / obs-local-part
So the local part can consist of a dot-atom or a quoted string (or some obsolete stuff they wish you wouldn’t use.) A dot-atom is defined in section 3.2.4 as follows:
atext = ALPHA / DIGIT / ; Any character except controls,
“!” / “#” / ; SP, and specials.
“$” / “%” / ; Used for atoms
“&” / “‘” /
“*” / “+” /
“-” / “/” /
“=” / “?” /
“^” / “_” /
“`” / “{” /
“|” / “}” /
“~”
atom = [CFWS] 1*atext [CFWS]
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *(“.” 1*atext)
The list of characters here doesn’t include the period, but the period still comes into play in dot-atom-text, where you’re allowed to have as many groups of atext as you like, separated by periods. Basically the only thing it doesn’t allow is consecutive periods. dot-atoms are also used for domain names and a few other things.
A quoted string is even more liberal. It’ll let you use any character except some of the control characters.
Chris, I’d be willing to bet that the spammers only use this tactic on gmail, since gmail is the only email provider I know of that does this. If that’s the case, then it would mean that they’re sending out the same amount of spam (as much as they can) but sending it to all the possible variations of all the addresses they can think of at gmail, in the hopes that it will enhance delivery rates.
I get this as well with my gmail and it drives me crazy. I’ve learned all about some other person from the email and it isn’t spam they are getting. These emails have usernames and passwords etc., in them.