Discussion:
Sending using my @debian.org in gmail
(too old to reply)
Joseph Herlant
2018-10-03 00:52:38 UTC
Permalink
Hi guys,

Wondering if anybody here succeeded to configure your debian email in
the "Send mail as" configuration in gmail (for the gmail users). If so
do you have tips on how you didi it?

My main problem seems to be that gmail forces the authentication and
master.debian.org doesn't allow it. It returns: "Unspecified Error
(SENT_SECOND_EHLO): Smtp server does not advertise AUTH capability,
code: 0"

I've also tried to send emails after configuring thunderbird but
encountered some issues as well. Seems master.debian.org doesn't allow
to send to non debian.org address, its that correct?

Thanks for your help,
Joseph
Alexandre Viau
2018-10-03 01:04:13 UTC
Permalink
Post by Joseph Herlant
Hi guys,
Wondering if anybody here succeeded to configure your debian email in
the "Send mail as" configuration in gmail (for the gmail users). If so
do you have tips on how you didi it?
I did.
Post by Joseph Herlant
My main problem seems to be that gmail forces the authentication and
master.debian.org doesn't allow it. It returns: "Unspecified Error
(SENT_SECOND_EHLO): Smtp server does not advertise AUTH capability,
code: 0"
It looks like you are trying to use Debian smtp servers. I just use
smtp.gmail.com.

There is a Gmail trick where you can add one send-as email and provide
smtp.gmail.com credentials.

You might have to create an app password.

I think that this guide does something similar to what I did:
-
https://blog.alexlenail.me/i-want-to-send-emails-from-my-google-domains-email-through-gmail-992bb3eae4c9

Let me know if this works out for you.

Cheer,
--
Alexandre Viau
***@debian.org
Joseph Herlant
2018-10-03 01:47:50 UTC
Permalink
Hi! :)
Post by Alexandre Viau
It looks like you are trying to use Debian smtp servers. I just use
smtp.gmail.com.
There is a Gmail trick where you can add one send-as email and provide
smtp.gmail.com credentials.
You might have to create an app password.
-
https://blog.alexlenail.me/i-want-to-send-emails-from-my-google-domains-email-through-gmail-992bb3eae4c9
Let me know if this works out for you.
Awesome, that works now. Thank you very much! :)

I'll add that to the wiki page in case somebody else gets the issue.

Joseph
Joseph Herlant
2018-10-03 02:00:22 UTC
Permalink
Post by Joseph Herlant
I'll add that to the wiki page in case somebody else gets the issue.
FYI: updated https://wiki.debian.org/MigrateToDDAccount with the details.
Not sure if that would be an issue to mention gmail specifically there
as it's vendor-specific. Feel free to remove it if it's a problem.

Joseph
Simon Quigley
2018-10-04 02:07:32 UTC
Permalink
Hello,
Post by Joseph Herlant
Post by Joseph Herlant
I'll add that to the wiki page in case somebody else gets the issue.
FYI: updated https://wiki.debian.org/MigrateToDDAccount with the details.
Not sure if that would be an issue to mention gmail specifically there
as it's vendor-specific. Feel free to remove it if it's a problem.
Ubuntu has some very detailed Gmail-specific documentation, I would
recommend that you grab relevant information from that as well:
https://wiki.ubuntu.com/UbuntuEmail
--
Simon Quigley
***@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4
Joseph Herlant
2018-10-04 17:16:41 UTC
Permalink
Hi Simon,
Post by Simon Quigley
Ubuntu has some very detailed Gmail-specific documentation, I would
https://wiki.ubuntu.com/UbuntuEmail
Thanks for the link pretty well explained. I added a note about it in
https://wiki.debian.org/MigrateToDDAccount

Joseph
殷啟聰 | Kai-Chung Yan
2018-11-30 14:17:47 UTC
Permalink
There is a Gmail trick where you can add one send-as email and provide smtp.gmail.com credentials.
You might have to create an app password.
https://blog.alexlenail.me/i-want-to-send-emails-from-my-google-domains-email-through-gmail-992bb3eae4c9
Just got my DD account and got the trick working, thanks for the tips!

However this worries me. During the setup there is no Debian involvement, and that means anyone can do the same trick to pretend to own my Debian address.
Jeremy Bicha
2018-11-30 14:27:50 UTC
Permalink
Post by 殷啟聰 | Kai-Chung Yan
However this worries me. During the setup there is no Debian involvement, and that means anyone can do the same trick to pretend to own my Debian address.
There is a confirmation email so a Bad Guy would have to be able to
read your email first.

Thanks,
Jeremy Bicha
Roberto C. Sánchez
2018-11-30 14:29:25 UTC
Permalink
Post by 殷啟聰 | Kai-Chung Yan
There is a Gmail trick where you can add one send-as email and provide smtp.gmail.com credentials.
You might have to create an app password.
https://blog.alexlenail.me/i-want-to-send-emails-from-my-google-domains-email-through-gmail-992bb3eae4c9
Just got my DD account and got the trick working, thanks for the tips!
However this worries me. During the setup there is no Debian involvement, and that means anyone can do the same trick to pretend to own my Debian address.
That is just how email works. With the help of a cooperating mail
server (which is trivial to setup) anybody in the world can send mail
with any from address that they wish. This problem is not unique to
Debian.

Regards,

-Roberto
--
Roberto C. Sánchez
Joseph Herlant
2018-11-30 16:04:47 UTC
Permalink
Post by 殷啟聰 | Kai-Chung Yan
Post by 殷啟聰 | Kai-Chung Yan
However this worries me. During the setup there is no Debian
involvement, and that means anyone can do the same trick to pretend to own
my Debian address.
That's also a reason why it's better to gpg-sign important email (aside
from the fact that anybody can have a setup that sends mails in your name
for any domain, even non-Debian).
Alexandre Viau
2018-11-30 17:49:02 UTC
Permalink
Post by Roberto C. Sánchez
That is just how email works. With the help of a cooperating mail
server (which is trivial to setup) anybody in the world can send mail
with any from address that they wish. This problem is not unique to
Debian.
Yes and no.

It is true that others are vulnerable, but this is a choice that Debian
makes and it can be fixed. If we wanted, we could largely limit this
with more restrictive debian.org DNS records.

When a mail server accepts incoming emails, it has the responsibility of
checking the mail comes from.

Debian can specify which servers it sends emails from and ask mail
servers around the world to only accept emails from these servers and
discard the others.

This is done trough DNS, with DMARC and SPF records:
- https://en.wikipedia.org/wiki/Sender_Policy_Framework
- https://en.wikipedia.org/wiki/DMARC

Currently, Debian does not publish such records so it opts out from this
protection.


== SPF example ==

I use gmail to send mails from ***@alexandreviau.net.

alexandreviau.net has the following TXT record:
- "v=spf1 include:_spf.google.com ~all"

It reads:
- version: spf1
- include google's SPF config, effectively authorizing everything that
google asks to authorize.
- ~ "SoftFail": don't take this rule too seriously but consider it when
filtering spam
- "all": match all addresses (not sure if we can specify one or groups..)

If I wanted, I could change "~all" to "-all" in my spf config, asking
mail servers to discard every emails that pretends to be from
alexandreviau.net but wasn't sent from google servers.

Cheers,
--
Alexandre Viau
***@debian.org
Michael Stone
2018-11-30 17:57:03 UTC
Permalink
Post by Alexandre Viau
It is true that others are vulnerable, but this is a choice that Debian
makes and it can be fixed. If we wanted, we could largely limit this
with more restrictive debian.org DNS records.
Yes and no. :) There would need to be a concerted push for some time to
migrate 20+ years of legacy configurations in order for this to not
break quite a lot.
Thomas Goirand
2018-12-05 13:58:08 UTC
Permalink
Post by Michael Stone
Post by Alexandre Viau
It is true that others are vulnerable, but this is a choice that Debian
makes and it can be fixed. If we wanted, we could largely limit this
with more restrictive debian.org DNS records.
Yes and no. :) There would need to be a concerted push for some time to
migrate 20+ years of legacy configurations in order for this to not
break quite a lot.
Absoultely not. Adding some DMARC records in our DNS doesn't break any
server not checking DMARC records.

Cheers,

Thomas Goirand (zigo)
Jeremy Stanley
2018-12-05 14:10:59 UTC
Permalink
Post by Thomas Goirand
Post by Michael Stone
Post by Alexandre Viau
It is true that others are vulnerable, but this is a choice that Debian
makes and it can be fixed. If we wanted, we could largely limit this
with more restrictive debian.org DNS records.
Yes and no. :) There would need to be a concerted push for some time to
migrate 20+ years of legacy configurations in order for this to not
break quite a lot.
Absoultely not. Adding some DMARC records in our DNS doesn't break any
server not checking DMARC records.
Migrating _client_ configurations/workflows to all submit via
Debian-controlled relays on the other hand would be necessary, to
avoid servers who check DMARC records rejecting messages from people
using their debian.org addresses in other ways (for example, yours
seems to have been sent through an MTA in GPLHost for relaying to
the lists.d.o MX).
--
Jeremy Stanley
Russ Allbery
2018-12-05 16:55:09 UTC
Permalink
Post by Jeremy Stanley
Post by Thomas Goirand
Absoultely not. Adding some DMARC records in our DNS doesn't break any
server not checking DMARC records.
Migrating _client_ configurations/workflows to all submit via
Debian-controlled relays on the other hand would be necessary, to
avoid servers who check DMARC records rejecting messages from people
using their debian.org addresses in other ways (for example, yours
seems to have been sent through an MTA in GPLHost for relaying to
the lists.d.o MX).
Right, the whole point of DMARC is to say that messages from a given
domain only originate from a small and well-defined set of servers, or
from servers with access to specific private key material.

Right now, people can use their debian.org address and send mail from
anywhere. For example, this message is being sent from my personal
servers and, were it not addressed to a Debian mailing list, would not go
anywhere near Debian infrastructure.

If we're not going to require that anyone sending mail from a debian.org
address do so through project infrastructure (which is a large change),
there's basically no point in doing anything with DMARC. It would only
increase the chances that mail not sent through Debian infrastructure
would be rejected by over-aggressive implementations that treat unknown as
failure.

Whether we want to continue to support that use case is certainly
something we can ask, and balance against the benefits of setting up
proper DMARC, SPF, DKIM, and so forth. The advantage would be that
project mail might be more reliably deliverable, and we would allow
receiving systems to discard more forged spam. The disadvantage is that
setting up infrastructure, documentation, and client configuration to send
all mail from debian.org addresses through project infrastructure would be
a lot of work, particularly since I'm sure that, in the grand Debian
tradition, there are at least as many ways we all send mail as there are
Debian developers.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Jeremy Stanley
2018-11-30 17:59:24 UTC
Permalink
On 2018-11-30 12:49:02 -0500 (-0500), Alexandre Viau wrote:
[...]
If we wanted, we could largely limit this with more restrictive
debian.org DNS records.
[...]

_And_ restrict those with @debian.org addresses to only sending them
through specific MTAs. Received headers indicate your message to
which I'm responding, just for example, was sent through GMail so
the change you're suggesting would preclude your current pattern of
E-mail usage.

SPF (and DKIM and other modern backscatter-limiting "solutions"
cooked up by mass mail hosters) doesn't fix this problem except by
killing much of the flexibility of traditional E-mail in the
process. Throwing out the baby with the bathwater.
--
Jeremy Stanley
Alexandre Viau
2018-11-30 18:17:51 UTC
Permalink
Post by Jeremy Stanley
[...]
If we wanted, we could largely limit this with more restrictive
debian.org DNS records.
[...]
through specific MTAs. Received headers indicate your message to
which I'm responding, just for example, was sent through GMail so
the change you're suggesting would preclude your current pattern of
E-mail usage.
Of course.

I just want to make sure that we know this is a choice.

Debian could provide MTAs and force DDs to use them if they want to send
from a @debian email. I would consider this reasonable.

DMARC allows to do this very slowly and progressively with warnings and
such.

The "flexibility" of sending mails from any MTA isn't really relevant if
you ask me. I could configure gmail to send mails trough Debian-hosted
SMTP servers and still use gmail to send my emails.

The real answer to "everyone can send from debian.org addresses" isn't:
"this is a generic email problem". The answer is: "Debian has this
problem because it wants to support everyone's workflows and configs".

It just isn't true that the common user wants to be able to send emails
from any MTA. Power users might, but the common user is happy to
configure its mail client however you tell him to.

Cheers,
--
Alexandre Viau
***@debian.org
Bernhard Schmidt
2018-12-03 15:00:36 UTC
Permalink
Am 30.11.18 um 20:05 schrieb Marc Haber:

Hi Marc,
If I could vote for which idea Debian mail admin time is dedicated
(which I cannot since Debian admins are volunteers and can choose what
to work on), I'd vote for better spam filtering on
@packages.debian.org and @alioth-lists.debian.net, probably using the
If you are the list admin (or know him) I've had good success on
pkg-voip-maintainers setting this in header_filter_rules

X-Alioth-Lists-Spam-Score-Int: [3-9][0-9]$

(that means hold everything with a Score >= 3.0 for moderation, while
the cutoff level on alioth-lists is 5.0

For pkg-voip-maintainers this had zero false-positives and about 1-2
spammails per day that are held for moderation. Of course you should
occasionally look at the moderation queue...

Bernhard
Raphael Hertzog
2018-12-06 11:11:04 UTC
Permalink
Hi,
Post by Bernhard Schmidt
If I could vote for which idea Debian mail admin time is dedicated
(which I cannot since Debian admins are volunteers and can choose what
to work on), I'd vote for better spam filtering on
@packages.debian.org and @alioth-lists.debian.net, probably using the
If you are the list admin (or know him) I've had good success on
pkg-voip-maintainers setting this in header_filter_rules
X-Alioth-Lists-Spam-Score-Int: [3-9][0-9]$
(that means hold everything with a Score >= 3.0 for moderation, while
the cutoff level on alioth-lists is 5.0
For pkg-voip-maintainers this had zero false-positives and about 1-2
spammails per day that are held for moderation. Of course you should
occasionally look at the moderation queue...
list manager.
*@packages.debian.org are just a plain aliases to maintainer emails (and
to the package tracker). But when maintainer emails point to mailing
lists, the above advice might still be relevant.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
Marco d'Itri
2018-11-30 18:45:21 UTC
Permalink
Post by Alexandre Viau
- https://en.wikipedia.org/wiki/DMARC
Among other issues, the BTS is still not compatible with DMARC.
--
ciao,
Marco
Paul Wise
2018-11-30 21:58:23 UTC
Permalink
Post by Alexandre Viau
Debian can specify which servers it sends emails from and ask mail
servers around the world to only accept emails from these servers and
discard the others.
Does this break the bounce/resend/redirect feature of various MUAs?
i.e., arbitrary parties must be able to redirect mail they have
received from d.o addresses to other parties via arbitrary SMTP
servers, with everyone still able to differentiate between forged d.o
mail and mail sent through d.o but redirected later by arbitrary
parties.
--
bye,
pabs

https://wiki.debian.org/PaulWise
Alexandre Viau
2018-11-30 22:17:29 UTC
Permalink
Post by Paul Wise
Post by Alexandre Viau
Debian can specify which servers it sends emails from and ask mail
servers around the world to only accept emails from these servers and
discard the others.
Does this break the bounce/resend/redirect feature of various MUAs?
i.e., arbitrary parties must be able to redirect mail they have
received from d.o addresses to other parties via arbitrary SMTP
servers, with everyone still able to differentiate between forged d.o
mail and mail sent through d.o but redirected later by arbitrary
parties.
DMARC/SPF don't have to deny bounces to achieve good security as long as
the original email was sent from a Debian MTA and signed with DKIM.

You can use DMARC to say that all outgoing Debian emails will be signed
by a domain key.

This means: If there is an email signed by debian.org's domain key that
pretends to come from ***@debian.org, then the owner of the debian.org
domain has done due diligence to verify that aviau actually wanted to
send that email (for example by allowing me to set an SMTP password in
db.debian.org).

Read about DKIM here:
- https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

DKIM was actually used in the past verify that leaked emails were legit:
- https://wikileaks.org/DKIM-Verification.html

DMARC, SPF and DKIM can be used together prevent almost all scenarios of
debian.org email spoofing.

Cheers,
--
Alexandre Viau
***@debian.org
Paul Wise
2018-11-30 22:29:44 UTC
Permalink
Post by Alexandre Viau
DMARC, SPF and DKIM can be used together prevent almost all scenarios
of debian.org email spoofing.
Which spoofing scenarios are not covered by this combination?
--
bye,
pabs

https://wiki.debian.org/PaulWise
Alexandre Viau
2018-11-30 22:32:23 UTC
Permalink
Post by Paul Wise
Post by Alexandre Viau
DMARC, SPF and DKIM can be used together prevent almost all scenarios
of debian.org email spoofing.
Which spoofing scenarios are not covered by this combination?
Ah, none that I know of.

I shouldn't have said that, I just didn't want to overstate the security
of a setup like this as I am not an email expert :)
--
Alexandre Viau
***@debian.org
Alexandre Viau
2018-12-01 17:36:07 UTC
Permalink
Post by Alexandre Viau
I shouldn't have said that, I just didn't want to overstate the security
of a setup like this as I am not an email expert :)
The people running the Debian mail system _are_ mail experts.
I haven't criticized anyone's work, this is just a discussion.
You should trust them do to a good job instead of reciting "spam filter"
marketing slides.
This comment brings nothing to the discussion. I don't know why your
tone is suddenly so aggressive.
Spam hasn't broken e-mail in two decades. Spam fighters are on a good
way to finally kill off e-mail.
Of course, nothing less.
--
Alexandre Viau
***@debian.org
Jeremy Stanley
2018-11-30 23:00:32 UTC
Permalink
Post by Paul Wise
Post by Alexandre Viau
DMARC, SPF and DKIM can be used together prevent almost all
scenarios of debian.org email spoofing.
Which spoofing scenarios are not covered by this combination?
Compromise of the cryptographic keys or primitives in use,
compromise of the authorized MTAs, compromise of the sender's
SMTP submission account, compromise of the sender's MUA/system, and
biggest of all of course is recipients who don't validate SPF/DKIM.
--
Jeremy Stanley
Paul Wise
2018-11-30 23:18:47 UTC
Permalink
Post by Jeremy Stanley
Compromise of the cryptographic keys or primitives in use,
compromise of the authorized MTAs, compromise of the sender's
SMTP submission account, compromise of the sender's MUA/system, and
biggest of all of course is recipients who don't validate SPF/DKIM.
Good points.

I've experienced spammers brute-forcing SMTP submission credentials
and using that to send spam before, so I think that mitigating that
using client-side TLS certs should be required, just as we do for SSH
access to Debian machines. I'm not sure how many MUAs support that but
MTAs do so using a local MTA to forward messages could be a
reasonablish workaround.
--
bye,
pabs

https://wiki.debian.org/PaulWise
Anthony DeRobertis
2018-12-01 06:10:22 UTC
Permalink
Post by Paul Wise
I've experienced spammers brute-forcing SMTP submission credentials
and using that to send spam before, so I think that mitigating that
using client-side TLS certs should be required, just as we do for SSH
access to Debian machines. I'm not sure how many MUAs support that but
MTAs do so using a local MTA to forward messages could be a
reasonablish workaround.
That honestly sounds like building a parallel system with at least as
much complexity as gpg, just to prevent a largely non-existent problem
(forged emails — the whole thread has been about its possible, but no
reports of it happening). Of course, gpg is also a better (from a
security standpoint) and more widely-supported solution. Which is
already deployed in Debian.

Though, for the record, it appears both Mutt and Thunderbird support TLS
client certificates.

Or you could just require strong passwords :-/
Paul Wise
2018-12-01 23:44:54 UTC
Permalink
Post by Anthony DeRobertis
That honestly sounds like building a parallel system with at least as
much complexity as gpg,
Such a system already exists, so it would presumably not have to be
built from scratch.

https://freerelay.err.no/

Systems that only allow mail to be sent when it is signed via OpenPGP
are usually much more limited in scope. The only ones I'm aware of are
***@db.d.o for updating LDAP via OpenPGP-signed messages,
*-***@lists.d.o for restricting announcement lists to Debian members and
perhaps things like schleuder.
Post by Anthony DeRobertis
just to prevent a largely non-existent problem
(forged emails — the whole thread has been about its possible, but no
reports of it happening). Of course, gpg is also a better (from a
security standpoint) and more widely-supported solution. Which is
already deployed in Debian.
My suggestion was to combat brute-force attacks against SMTP auth
passwords leading to spammers sending mail from the debian.org MXen
and getting Debian banned from sending mail to most of the SMTP
servers on the Internet. This suggestion only improves a small part of
the existing discussion about domain-based email authentication.
Post by Anthony DeRobertis
Though, for the record, it appears both Mutt and Thunderbird support TLS
client certificates.
Thanks for that data point.
Post by Anthony DeRobertis
Or you could just require strong passwords :-/
We do not rely on passwords for uploading to the archive or logging
into debian.org machines with SSH and I think the same should apply to
as many debian.org authentication systems as possible. In 2018, it is
many years past time to stop using passwords in general (with
exceptions for things like local auth and local encryption).
--
bye,
pabs

https://wiki.debian.org/PaulWise
Tollef Fog Heen
2018-12-01 09:46:27 UTC
Permalink
]] Alexandre Viau
Post by Alexandre Viau
It is true that others are vulnerable, but this is a choice that Debian
makes and it can be fixed. If we wanted, we could largely limit this
with more restrictive debian.org DNS records.
I would say «changed» rather than fixed, since I don't think the current
setup is wrong.

One problem with providing outbound SMTP service is that we'd end up
with a bunch of user support requests when inevitably something didn't
work. DSA already has enough work to do that we'd rather not have that
extra load.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Continue reading on narkive:
Loading...