Sending using my @debian.org in gmail

[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?

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]

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,

[Joseph Herlant]

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]

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]

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

[Joseph Herlant]

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]

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]

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]

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

[Joseph Herlant]

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]

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,

[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.

[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.

Cheers,

Thomas Goirand (zigo)

[Jeremy Stanley]

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).

[Russ Allbery]

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.

[Jeremy Stanley]

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.

[Alexandre Viau]

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,

[Bernhard Schmidt]

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]

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,

[Marco d'Itri]

Post by Alexandre Viau
- https://en.wikipedia.org/wiki/DMARC

Among other issues, the BTS is still not compatible with DMARC.

[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.

[Alexandre Viau]

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,

[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?

[Alexandre Viau]

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]

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.

[Jeremy Stanley]

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.

[Paul Wise]

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.

[Anthony DeRobertis]

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]

This post might be inappropriate. Click to display it.

[Tollef Fog Heen]

]] 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.