Quantcast

Erroneous handling of addresses containing a '@' character

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Erroneous handling of addresses containing a '@' character

Koszta Dániel
I'm running Postfix v3.2.0 and have found that if I try to write an
email to <"user@whatever"@domain.tld>, I get back a bounce error stating

    Host or domain name not found. Name service error for name=whatever
    type=AAAA: Host not found

Note that a DNS lookup failed for "whatever" while that is the
local-part of the address and therefore it makes no sense to look up.

While very unusual, '@' characters are allowed to be part of the
local-part of email addresses when properly quoted and therefore I think
this is a bug in Postfix.

This also has a mild security implication: if someone were to
(legitimately) have a <"[hidden email]"@domain.tld> email address,
than that message would be delivered to malicious.tld instead of
domain.tld. Some sort of DoS attack may also be feasible if
"malicious.tld" were a correctly set up relay server, causing such
emails to bounce back and forth.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erroneous handling of addresses containing a '@' character

Wietse Venema
Koszta D?niel:
> This also has a mild security implication: if someone were to
> (legitimately) have a <"[hidden email]"@domain.tld> email address,
> than that message would be delivered to malicious.tld instead of
> domain.tld. Some sort of DoS attack may also be feasible if

At your own risk, you can set 'resolve_dequoted_address = no'. See
http://www.postfix.org/postconf.5.html#resolve_dequoted_address for
some background.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erroneous handling of addresses containing a '@' character

Koszta Dániel
> At your own risk, you can set 'resolve_dequoted_address = no'. See > http://www.postfix.org/postconf.5.html#resolve_dequoted_address for > some background.
Thank you.

The documentation you linked says:

> This opens opportunities for obscure mail relay attacks with > user@domain@domain addresses when Postfix provides backup MX service > for Sendmail systems.

That sounds like there is a bug in Sendmail. Is that still not fixed? Or is there otherwise a reason to keep 'resolve_dequoted_address=yes' as a default? (I tried searching for what the problem is, but couldn't find it.)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erroneous handling of addresses containing a '@' character

Wietse Venema
Koszta Daniel:

> > At your own risk, you can set 'resolve_dequoted_address = no'. See > http://www.postfix.org/postconf.5.html#resolve_dequoted_address for >
> some background.
> Thank you.
>
> The documentation you linked says:
>
> > This opens opportunities for obscure mail relay attacks with
> > user@domain@domain addresses when Postfix provides backup MX service
> > for Sendmail systems.
>
> That sounds like there is a bug in Sendmail. Is that still not fixed? Or
> is there otherwise a reason to keep 'resolve_dequoted_address=yes' as a
> default? (I tried searching for what the problem is, but couldn't find it.)

Based on Internet-wide research you came to the conclusion that
Sendmail is/was the only MTA in existence with such a bug.

I would not be so optimistic. The purpose of Postfix is to deliver
email safely, not to expose bugs in other email handling software.
Postfix provides controls to override that, but it is not the default.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Safe] handling of addresses containing a '@' character

Viktor Dukhovni
In reply to this post by Koszta Dániel

> On Apr 17, 2017, at 8:25 AM, Koszta Dániel <[hidden email]> wrote:
>
> I'm running Postfix v3.2.0 and have found that if I try to write an
> email to <"user@whatever"@domain.tld>, I get back a bounce error stating
>
>    Host or domain name not found. Name service error for name=whatever
>    type=AAAA: Host not found
>
> Note that a DNS lookup failed for "whatever" while that is the
> local-part of the address and therefore it makes no sense to look up.

Sometimes what's sensible and what complies with the standards don't
coincide.  When the sensible is sufficiently compelling, Postfix goes
with what makes more sense.

> While very unusual, '@' characters are allowed to be part of the
> local-part of email addresses when properly quoted and therefore I think
> this is a bug in Postfix.

No, not a bug, this is a sensible design choice.

> This also has a mild security implication: if someone were to
> (legitimately) have a <"[hidden email]"@domain.tld> email address,
> than that message would be delivered to malicious.tld instead of
> domain.tld.

No, because Postfix will block that as a "relay" attempt.  Indeed
the opposite is true. If you disable special handling of quoted
"user@domain" localparts, you may become open to relay attacks
when Postfix hands off mail to downstream mail systems.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Safe] handling of addresses containing a '@' character

Koszta Dániel
Wietse Venema:

> Based on Internet-wide research you came to the conclusion that > Sendmail is/was the only MTA in existence with such a bug.

Obviously not. I just thought that the documentation implied that it was
a specific issue with Sendmail that only mattered in cases when "Postfix
provides backup MX service for Sendmail systems".

> The purpose of Postfix is to deliver email safely, not to expose > bugs in other email handling software.

I'd argue that attempting to deliver mail intended for
<"[hidden email]"@example.com> to whoever controls domain.tld is _not_
safe.

Viktor Dukhovni:

> No, because Postfix will block that as a "relay" attempt.

That depends on some other circumstances. E.g. I have set my server up
such that if I try to send mail as an authenticated user, it will
"relay" it. When I tried to send an email to
<"[hidden email]"@mydomain.tld>, I see log entries like this:

postfix/smtp[15952]: connect to
gmail-smtp-in.l.google.com[2a00:1450:400c:c08::1b]:25: Network is
unreachable

indicating that an attempt was made to deliver it to gmail's servers.
(This is just a PC on a residential IPv4 address, so I don't expect
outgoing mail to actually arrive to most places.)

> When the sensible is sufficiently compelling, Postfix goes with what > makes more sense.

That's fine, but in this case the "sensible" option would be to _drop_
the mail, instead of trying to deliver it elsewhere.

(I may be missing something, though, as when I try to send mail to
<"[hidden email]"@example.com>, it tries to connect to example.com
and not mydomain.tld. I'm not sure why it's different this way...)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Safe] handling of addresses containing a '@' character

Wietse Venema
Koszta D?niel:
> That's fine, but in this case the "sensible" option would be to _drop_
> the mail, instead of trying to deliver it elsewhere.

The safe default is to reject, not discard. Discard assumes malice,
and there is no need to assume that here.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Safe] handling of addresses containing a '@' character

Viktor Dukhovni
In reply to this post by Koszta Dániel

> On Apr 17, 2017, at 12:45 PM, Koszta Dániel <[hidden email]> wrote:
>
>
> I may be missing something, though, as when I try to send mail to
> <"[hidden email]"@example.com>, it tries to connect to example.com
> and not mydomain.tld. I'm not sure why it's different this way...

This is correct behaviour.  The dequoted localpart becomes the real
destination *only* when the domainpart is a local domain.  When
the domainpart (e.g. example.net) is a remote domain, the address
"[hidden email]"@example.net is relayed to "example.net".

However, such mail is only accepted when the client is trusted.
The feature you were calling a bug *defends* against relay
attempts from unauthorized clients.  Authorized clients can
already send to any domain, so there's no need for them to
be creative and hide the destination in the localpart.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Safe] handling of addresses containing a '@' character

Koszta Dániel
>> I may be missing something, though, as when I try to send mail to >> <"[hidden email]"@example.com>, it tries to connect to >>
example.com and not mydomain.tld. I'm not sure why it's different >>
this way... > This is correct behaviour.  The dequoted localpart becomes
the real > destination *only* when the domainpart is a local domain.
When the > domainpart (e.g. example.net) is a remote domain, the address
> "[hidden email]"@example.net is relayed to "example.net". >

I agree, but my concern was that when I sent a mail to
<"[hidden email]"@mydomain.tld>, I saw log entries like this:

postfix/smtp[15952]: connect to
gmail-smtp-in.l.google.com[2a00:1450:400c:c08::1b]:25: Network is
unreachable

indicating that an attempt was made to deliver it to gmail's servers.
_That_ is what I see as problematic. I undertand that this is not
_really_ important, but I fail to see why this would be correct or
expected. (Then again, I may just be short-sighted...)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Safe] handling of addresses containing a '@' character

D'Arcy Cain
In reply to this post by Koszta Dániel
On 2017-04-17 12:45 PM, Koszta Dániel wrote:
> That's fine, but in this case the "sensible" option would be to _drop_
> the mail, instead of trying to deliver it elsewhere.

Not unless you run a toy system for your own use.  As an email provider
I promise my users that there are only two options - reject or deliver.
When I reject something legitimate (false positive) the sender is
advised that something went wrong and can take corrective action.  I do
provide tools to my users so that they can filter themselves if they see
fit but I never make that decision for them.

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:[hidden email]
VoIP: sip:[hidden email]
Loading...