Send as feature and the "Sender" header field
vike the hube
haven't, when you use Gmail to send from another email address, it also
adds your Gmail address in the "Sender" field. This means it shows up
on many clients, and is available to everyone. Google seems to have
acknowledged the problem years ago but hasn't done anything about it. I
thought this might be because they had some reasons, so I tried to
address these and posted this to
https://services.google.com/inquiry/gmail_suggest/ :
Eliminate the sending of the "Sender: x...@gmail.com" field when using the
"send as" feature- that is, when sending from a non-Gmail address,
DON'T include the Gmail address in the headers, or make it an option to
turn it on or off.
Why?
1. It is NOT actually required by RFC 2822, available at
ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt . There are two cases
where the Sender field is mentioned:
'If the from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name "Sender"
and a single mailbox specification, MUST appear in the message';
and "The "Sender:" field specifies the mailbox of the agent responsible
for the actual transmission of the message. For example, if a
secretary were to send a message for another person, the mailbox of the
secretary would appear in the "Sender:" field and the mailbox of the
actual author would appear in the "From:" field. If the originator of
the message can be indicated by a single mailbox and the author and
transmitter are identical, the "Sender:" field SHOULD NOT be used.
Otherwise, both fields SHOULD appear.".
This implies that the Sender field should only be used as a kind of
courtesy in the case that the sender is not the same PERSON as the from
address, as in the secretary example given. It clearly is not an
anti-spam precaution, (further discussed below) which is covered by 'In
all cases, the "From:" field SHOULD NOT contain any mailbox that does
not belong to the author(s) of the message.', something that Gmail
already checks with its verification email.
In addition, it explicitly DOES NOT REQUIRE that the Sender field be
present or not be present in certain situations- it uses the terms
"SHOULD" and "SHOULD NOT", as opposed to the earlier "MUST". These are
defined as follows in RFC 2119, available at
ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt :
'3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed before
implementing any behavior described with this label.'
Note that deviations from these ARE permitted, so long as there is
sufficient reason- reasons are discussed below.
Even so, the RFC states 'If the originator of the message can be
indicated by a single mailbox and the author and transmitter are
identical, the "Sender:" field SHOULD NOT be used.'- the originator of
the message CAN be indicated by a single mailbox, as Gmail has already
verified the validity of the user's other mailbox; and the author and
transmitter MUST be identical, must be the same person, as otherwise
Gmail's verification would have failed. So even by the RFC's wording,
it recommends that the Sender field should not be present.
2. There are those who have suggested that the Sender field was created
with anti-spam ideas in mind. This is simply not the case. Firstly,
there is no way that the information in the Sender or From fields can
be verified as not forged, so any checking for bad senders will fail
anyway. Secondly, the RFC itself gives an example of someone sending
mail "on behalf of" someone else- not using the Sender field as an
anti-spam measure. Thirdly, there already exists a strong and
verifiable header system for checking the originating server of an
email- the "Received" field, which lists servers the mail has traversed
through, and that can be verified at each step; and the other extended
spam headers added by mail servers. Fourthly, as already stated,
Gmail's verification email system eliminates the possibility of a
spammer appearing to send from someone else's account. Finally, it
actually works against the anti-spam uses of the Gmail "Send as"
feature, as mentioned in point 3 below.
3. It's bad for users. The whole point of this feature is so that users
may send mail from another mailbox they own, while still using Gmail's
excellent archiving and other features. Examples of this use include:
users who wish to send from a professional looking corporate address,
instead of their personal account, but wish to use their personal
account's great features; users who give out a different email address
to everyone who requests it, so that if someone starts spamming, they
know who and can stop it; and those who have several different personal
email accounts they would like to keep segregated. Adding the "Sender"
header item defeats the whole purpose of the "send as" feature, as it
allows all these uses to be thwarted. It actually makes it HARDER for
users to fight spam. Isn't Google all about what's best for their
users? "Google's mission is to organize the world's information and
make it universally accessible and useful"- which Google has done with
their excellent email service. However, Google is making our email
address information more useful to spammers, and less useful to users.
I have seen many users say they will leave Gmail and go back to Yahoo
or using a mail client because of this problem.
4. It is accepted industry practice that this Sender header can be
changed at will. Every single mail client available allows you to
change the from address, albeit without a clever verification technique
similar to that Gmail has implemented. Every mail service in the world
allows you to change the from address. I've already explained that
Gmail isn't holding up the standard, as the standard doesn't require
it, and that Gmail isn't preventing any spam, probably the opposite, so
why must Gmail go against the grain of industry practice? The internet
standards did not come first- the protocols did. The standards are an
attempt to capture the industry use of these protocols in a formal
sense. So Gmail being the exception in the industry with respect to a
particular poor interpretation of the standard simply does not make
sense.
Summing up, with respect to Gmail's "send as another address" feature,
I would like to see the "Sender" field either removed, or made
optional. This is because: it is NOT required by the standard, only
recommended, and the standard suggests it can be bypassed with
sufficient reason, which I have given; it does NOT prevent spam, and in
fact causes problems for users trying to prevent spam; users are turned
off by the problem, and many have said they will leave Gmail because of
it; and Gmail is going against the grain of industry with this
behaviour, despite the fact that the standard is based off industry
practice.
Here is a quote of the entire relevant RFC 2822 section:
'3.6.2. Originator fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be
indicated
by a single mailbox and the author and transmitter are identical,
the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the mailbox(es) to which the author of the message
suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in
the
"From:" field unless otherwise specified by the person composing the
reply.
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message. See also section
3.6.3 for more information on forming the destination addresses for
a
reply.'
Zack (Doc)
here, but you missed the point of the people chanting about it's
"anti-spam" function.
It's not that they're saying it's to prevent spam for the users, but
to prevent users from being identified as spam.
Some spam filters (filtering companies) set an automatic "match" if
the sender's domain and the domain of the first SMTP server do not
match. For this reason, the setting of "Sender:" helps. This
prevents this type of false positive match, if you're using GMail's
SMTP servers (meaning webmail users as well as ones not using local
ISP SMTP servers). That said, I think I've heard reports that people
using POP/SMTP with GMail have had complete success with setting their
own "From:" without a "Sender:" being appended. I don't know, cause
I'm not a user like that.
On 6/14/06, vike the hube <viket...@gmail.com> wrote:
>
> I'm sure everyone has already heard a lot about this. For those who
> haven't, when you use Gmail to send from another email address, it also
> adds your Gmail address in the "Sender" field. This means it shows up
<large posting clipped>
Fuzzy Logic
On 6/14/06, vike the hube <viket...@gmail.com> wrote:
> Eliminate the sending of the "Sender: x...@gmail.com" field when using the
> "send as" feature
>
> Why?
> 1. It is NOT actually required by RFC 2822:
> "If the originator of
> the message can be indicated by a single mailbox and the author and
> transmitter are identical, the "Sender:" field SHOULD NOT be used.
> Otherwise, both fields SHOULD appear.".
>
> This implies that the Sender field should only be used as a kind of
> courtesy in the case that the sender is not the same PERSON as the from
> address
I don't read the RFC that way. I read it as saying that if the
mailboxes are the same, don't include the Sender field. (example:
b...@gmail.com and b...@googlemail.com)
> 2. There are those who have suggested that the Sender field was created
> with anti-spam ideas in mind. This is simply not the case.
So? It allows someone to know which Gmail address was used to send the
message in the case where the original mailbox was no longer
reachable.
> 3. It's bad for users.
How? Why should a user have a problem with this? What kind of problems
would they have?
> 4. It is accepted industry practice that this Sender header can be
> changed at will.
So, why is there a problem with Gmail doing what they are doing? If a
mailing list rewrites the From, I would expect it would also rewrite
Sender properly as well.
> Summing up, with respect to Gmail's "send as another address" feature,
> I would like to see the "Sender" field either removed, or made
> optional. This is because: it is NOT required by the standard,
Okay, if it's optional, and Gmail chooses to do it, that is their
perogative. There are a large number of RFCs that suggest things that
are considered "must-dos" even when the RFC says "SHOULD". I
appreciate your opinion, but I think you are wrong.
Fuzzy
--
Latin: Dum spiro spero.
English: While I breathe, I hope.
vike the hube
<snip>
> Some spam filters (filtering companies) set an automatic "match" if
> the sender's domain and the domain of the first SMTP server do not
> match. For this reason, the setting of "Sender:" helps. This
> prevents this type of false positive match, if you're using GMail's
> SMTP servers (meaning webmail users as well as ones not using local
> ISP SMTP servers). That said, I think I've heard reports that people
> using POP/SMTP with GMail have had complete success with setting their
> own "From:" without a "Sender:" being appended. I don't know, cause
> I'm not a user like that.
>
Yes, that's probably the case. I don't think it should affect whether
or not I can choose to turn off the "Sender" field, though. This is a
valid concern, so maybe along with the option to turn off the "Sender"
field should be a warning that it may cause your messages to be flagged
as spam. It's irrelevant, but I must say, though, that it's a pretty
poor technique for flagging spam, as many users all over do in fact use
clients (most clients) that throw away the "Sender" field without even
telling the user the consequences.
vike the hube
<snip>
> I don't read the RFC that way. I read it as saying that if the
> mailboxes are the same, don't include the Sender field. (example:
> b...@gmail.com and b...@googlemail.com)
Yes, I can see how it can be read that way as well. It is, however,
still a "SHOULD" requirement, and is optional if there is sufficient
reason, which I believe I give.
> > 2. There are those who have suggested that the Sender field was created
> > with anti-spam ideas in mind. This is simply not the case.
>
> So? It allows someone to know which Gmail address was used to send the
> message in the case where the original mailbox was no longer
> reachable.
Ah, yes, the unreachable mailbox would be a flaw in having only Gmail's
verification process, as it doesn't constantly check to see if the
address is still valid. But I think that's a minor flaw- the sender
would have owned that address in the first place, and surely they would
realise that it was now unreachable. If this was a problem, Gmail could
require monthly verification of send-as addresses.
>
> > 3. It's bad for users.
>
> How? Why should a user have a problem with this? What kind of problems
> would they have?
As I mentioned, some users (for example, me :P) have many forwarding
email addresses that forward to a "secret" account, for anti-spam
purposes. Each online service I give my email to gets a new forwarder.
If no one gets the secret account, then I never have to throw it away,
as no one can ever spam it. If someone starts spamming one of the
forwarders, I know who it was, and I can simply turn it off and the
spam will stop. I used to use an ISP account as my secret account, but
Gmail is the best mail service I've seen, and its implementation of the
send as feature is brilliant, aside from this hassle. If someone has
sent an email to one of my forwarders, and I have registered this as an
account in Gmail, I simply hit reply and it will reply from the
forwarder, not my Gmail account. The "Sender" field is a problem
because when I do this, in many mail clients it shows
"myad...@gmail.com on behalf of myfor...@mydomain.com", and
ultimately users, and more importantly the spammers I am trying to
avoid, can easily find out my secret address. Even if it didn't show as
"on behalf of", or as "sender", like it does in Thunderbird, it would
be available in the headers, and my address would no longer be secret.
That's why it's bad for me.
Another example I have read about is users who send work-related emails
from their personal Gmail account, and use the send as feature to send
as their work account. The commonly-used-in-business-setting Outlook is
one of the clients that shows the address as "on behalf of", and these
users really don't want their often inappropriate personal account to
be shown.
Most users I've seen complaining about this issue say they'll do one of
three solutions: That they'll go to a different provider, such as
Yahoo, that offers this feature without the "Sender" field; that
they'll go back to using an external client for sending mail, with
Gmail's SMTP servers; or that they'll go to using a free and
limited/unreliable or paid spam service, such as spamgourmet. Using an
external client does work, as Zack mentioned, and so I don't see why
there should not be an option to do a similar thing from Gmail's
excellent web-based interface.
> > 4. It is accepted industry practice that this Sender header can be
> > changed at will.
>
> So, why is there a problem with Gmail doing what they are doing? If a
> mailing list rewrites the From, I would expect it would also rewrite
> Sender properly as well.
I don't understand what you mean.
What I meant was that every mail client I've seen allows you to send
from another account without the "Sender" field, and most web-based
clients also. In fact, the majority of them do so without even telling
you that there is the optional "Sender" field. Gmail is the only
service I have seen that is the exception to this. Of course, that's a
bad argument in itself, it's a classic ad populum. However, these
standards were written from industry's practice, they are "live"
standards if that's the right term. The standard IS what everyone does.
It's the same as the English language- this sentence is probably not
grammatically correct English, but English is a living language, and
changes with the times.
> Okay, if it's optional, and Gmail chooses to do it, that is their
> perogative. There are a large number of RFCs that suggest things that
> are considered "must-dos" even when the RFC says "SHOULD".
This is not one of those "must-dos" where the RFC says "SHOULD",
though, as Gmail's web interface is the first client I have seen that
does implement it. If Gmail chooses to do it, that's fair enough; but I
believe they are losing users over it, or at least decreasing the
happiness of some of them. I think an option to turn off the "Sender"
field that defaults to leaving the field in would be very welcome.
> I appreciate your opinion, but I think you are wrong.
That's fair enough too :-)
Zack (Doc)
> poor technique for flagging spam, as many users all over do in fact use
I never said it was a good technique, just that it's used. I agree
there are MANY other good ways to verify senders, that are not
employed, and many horrible ways to "detect spam" that are employed.
vike the hube
approach, so that users can be made aware that it may cause problems.
vike the hube
my feature request? And what are my chances of getting some kind of
positive or negative feedback? I'd like to know if I should find
another solution.
Zack (Doc)
reading your feature request? based on the past results I've seen, pretty high
feedback? This I've never heard of receiving directly.
