Mailing List Archive

Adrien de Croy wrote:

> However from the SPF spec, any spammer can get around SPF simply by
>
> a) not providing a FQDN in the HELO/EHLO command (since this is not
> mandated by RFC 2821); and
> b) specifying a blank return path in the MAIL command.

In most cases mail with an empty return-path is a delivery status
notification sent to the envelope sender of the original mail. If that
envelope sender was signed, you can simply put all mail with an empty
return-path and a non-signed recipient to the junk folder. You might need
some white list to allow auto-replies to go through.

Roger

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Hi Roger, thanks for your reply

At 29/05/2004 20:45, Roger Moser wrote:
>Adrien de Croy wrote:
>
> > However from the SPF spec, any spammer can get around SPF simply by
> >
> > a) not providing a FQDN in the HELO/EHLO command (since this is not
> > mandated by RFC 2821); and
> > b) specifying a blank return path in the MAIL command.
>
>In most cases mail with an empty return-path is a delivery status
>notification sent to the envelope sender of the original mail.

we find on our server that about 99.5% of mail with a blank return path is
spam, rather than a DSN, since we always deliver direct to MX, it is very
rare to get a DSN... since that would only occur in the cases where the MX
server then relays on to another server. We of course generate our own DSN
if necessary, but then this is something we are generating not receiving.

>If that envelope sender was signed, you can simply put all mail with an empty
>return-path and a non-signed recipient to the junk folder. You might need
>some white list to allow auto-replies to go through.

OK, sorry if this is a dumb question, but what do you mean by signed?

I guess you don't mean cryptographically signed?

I thought basically that the MTA on the other end generating a DSN, created
their own message back to the original envelope sender. This message may
have any headers, may not necessarily copy anything back from the original
message etc.

Or does this rely on the DSN extension for ESMTP?

Cheers

Adrien



>Roger
>
>-------
>To unsubscribe, change your address, or temporarily deactivate your
>subscription,
>please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

------------------------------------------------------------------------
Adrien de Croy Qbik New Zealand Limited
The makers of WinGate, and WinGate VPN.
http://www.qbik.com/
------------------------------------------------------------------------
check out the new WinGate website http://www.wingate.com
------------------------------------------------------------------------

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

I think I get it now.

So you take a return path when you accept a mail for forwarding. You sign
it (say salted MD5 or something prepended to the address with a delimiter),
you specify that as the return path when you forward the mail. Then you
know when you get a recipient command back, if there is a signature on the
recipient, which you can verify by parsing the signature off, you validate
it, therefore you know that the MTA on the other end is the one that
received the message, and therefore it is ok to have a blank return path.

This is an interesting idea, but I guess there are a couple of
complications with this approach:

a) it breaks banlists on receiving servers, since the return path has been
altered. So if you wanted to block all mail from bob@somewhere.com, and it
came in instead as xxxxx.bob@somewhere.com because it was signed, then your
rules wouldn't match, and people couldn't know what rule to set either.

b) if a reply is ever generated not based on the envelope return path (but
rather say the RFC822 Reply-to: header) such as would be the case for
delivery of a DSN from a POP3 retrieval agent from a catchall account, or
relayed delivery, or off-line processed response from say a virus filter
etc, then the legitimate DSN would not have the signed address, and would
be blocked if there was no return path.

Personally I would like to see the blank return path made illegal in SMTP
(c'mon guys... if we all get together...)

If you think about it, having a blank return path is the same as saying
"no-one is prepared to take responsibility for this email / the actions of
this machine". The concept of allowing a machine to automatically do
something that no human is prepared to take responsibility for is contrary
to the laws of every country on the planet (e.g. noone believes that the
responsibility for the actions of a cruise missile should be its own).

I will go have a look for an RFC for this sender signing... thanks for the tip!

Cheers

Adrien


At 29/05/2004 20:45, Roger Moser wrote:
>Adrien de Croy wrote:
>
> > However from the SPF spec, any spammer can get around SPF simply by
> >
> > a) not providing a FQDN in the HELO/EHLO command (since this is not
> > mandated by RFC 2821); and
> > b) specifying a blank return path in the MAIL command.
>
>In most cases mail with an empty return-path is a delivery status
>notification sent to the envelope sender of the original mail. If that
>envelope sender was signed, you can simply put all mail with an empty
>return-path and a non-signed recipient to the junk folder. You might need
>some white list to allow auto-replies to go through.
>
>Roger
>
>-------
>To unsubscribe, change your address, or temporarily deactivate your
>subscription,
>please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

------------------------------------------------------------------------
Adrien de Croy Qbik New Zealand Limited
The makers of WinGate, and WinGate VPN.
http://www.qbik.com/
------------------------------------------------------------------------
check out the new WinGate website http://www.wingate.com
------------------------------------------------------------------------

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Adrien de Croy wrote:

> a) it breaks banlists on receiving servers, since the return path has been
> altered. So if you wanted to block all mail from bob@somewhere.com, and
it
> came in instead as xxxxx.bob@somewhere.com because it was signed, then
your
> rules wouldn't match, and people couldn't know what rule to set either.

There should be some standard for signing an email address, for example by
separating the signature by a certain character. (I read somewhere that such
a character is already defined but I forget where I read it). So the signed
address would be e.g. bob=xxxxx@somewhere.com and filters should ignore the
part after the '='.

> b) if a reply is ever generated not based on the envelope return path (but
> rather say the RFC822 Reply-to: header) such as would be the case for
> delivery of a DSN from a POP3 retrieval agent from a catchall account, or
> relayed delivery, or off-line processed response from say a virus filter
> etc, then the legitimate DSN would not have the signed address, and would
> be blocked if there was no return path.

In such cases the return-path should be something like
<no-reply@example.com>.

> Personally I would like to see the blank return path made illegal in SMTP
> (c'mon guys... if we all get together...)

For delivery status notifications and auto-replies the return-path must be
empty to avoid ping pong games.
Currently the delivery status notifications with all the different formats
are a mess and difficult to be processed by a program.
An empty return-path should only be used to send a delivery status message
or an auto-reply by writing a message/delivery-status, and the receiver
should parse the message/delivery-status part and ignore anything else.

Roger

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

>However from the SPF spec, any spammer can get around SPF simply by
>
>a) not providing a FQDN in the HELO/EHLO command (since this is not
>mandated by RFC 2821); and
>b) specifying a blank return path in the MAIL command.

This doesn't allow a spammer to "get around" SPF. From the RFC, I believe this would result in either an SPF "unknown" (if the HELO is ""), or a SPF "none" (if the HELO contains something).

If you are using the SPF results for a spam filter, then "unknown" and "none" will indicate a message more likely to be spam.

If you are rejecting everything that doesn't "pass" (something we will only be able to do after widespread adoption), then the message will be rejected.

A real issue might be "Are there a lot of MTAs that do not use a FQDN in HELO when sending a DSN?" because these MTAs will eventually find their DSNs ignored by the rest of the Internet.

Michael R. Brumm

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

At 30/05/2004 08:53, Roger Moser wrote:
>Adrien de Croy wrote:
>
> > a) it breaks banlists on receiving servers, since the return path has been
> > altered. So if you wanted to block all mail from bob@somewhere.com, and
>it
> > came in instead as xxxxx.bob@somewhere.com because it was signed, then
>your
> > rules wouldn't match, and people couldn't know what rule to set either.
>
>There should be some standard for signing an email address, for example by
>separating the signature by a certain character. (I read somewhere that such
>a character is already defined but I forget where I read it). So the signed
>address would be e.g. bob=xxxxx@somewhere.com and filters should ignore the
>part after the '='.

I read the spec for SRS. Interesting as well, although I thought that
source routing of mail was deprecated for REALLY good reasons, so
re-introducing it I think is dangerous. Also it looks convoluted to
implement which will doubtless lead to implementation errors.

As for signing though, since the original server should be the one that
forwarded the mail, and would receive a DSN, then I guess it should be able
to pick any mechanism it likes for signing, as long as such mechanism is
transparent to SMTP (i.e. it gets the same address back). I'll keep
looking for a spec - thanks for the tip again, this one could be quite
promising.

> > b) if a reply is ever generated not based on the envelope return path (but
> > rather say the RFC822 Reply-to: header) such as would be the case for
> > delivery of a DSN from a POP3 retrieval agent from a catchall account, or
> > relayed delivery, or off-line processed response from say a virus filter
> > etc, then the legitimate DSN would not have the signed address, and would
> > be blocked if there was no return path.
>
>In such cases the return-path should be something like
><no-reply@example.com>.
>
> > Personally I would like to see the blank return path made illegal in SMTP
> > (c'mon guys... if we all get together...)
>
>For delivery status notifications and auto-replies the return-path must be
>empty to avoid ping pong games.
>Currently the delivery status notifications with all the different formats
>are a mess and difficult to be processed by a program.
>An empty return-path should only be used to send a delivery status message
>or an auto-reply by writing a message/delivery-status, and the receiver
>should parse the message/delivery-status part and ignore anything else.

understand the loop issues, however in my view, a responsible MTA who
generates a DSN should be prepared to take responsibility for that DSN as
well. It therefore should specify a return path that it is prepared to
guarantee will work - e.g. postmaster@somewhere.com. Then if the DSN is
bounced because the original return path was bogus, it goes back to the MTA
that generated the DSN and stops there. Any MTA that specifies bogus
return paths for DSNs could then be the subject of a blacklist.... the
resources are available - we could re-use the blacklists currently used to
punish MTAs that block blank return-paths :).

There is another problem scenario with SPF as well.

Customers of ISPs who use dynamic IP addresses, and don't host their own
DNS and don't host their own mail servers, yet deliver direct to MX from
their dynamic IPs. So the MX never matches the deliverer of mail from that
domain. Since DNS for that domain is also hosted by the ISP, this person
can't implement SPF, unless their ISP does it for them, and ties in the IPs
with the currently assigned IP for their account. If they don't have the
means to do this, then it's not going to happen.

As long as there are a significant number of domains that can't implement
SPF to block forgery, there will be a significant number of domains that
spammers can use as their return paths. It's easy for spammers (and the
next SMTP-engine-equipped virus) to only use return paths where the domain
has no SPF record. Also (as at today) hotmail.com and yahoo.com still have
no SPF records.

Why I am saying this is that I think that (since I hate spam so much)
unless developers of mail server software put in a fallback verification
system that doesn't rely on the existence of SPF records, then there will
always be a really big hole for spammers to spam through. SPF is great
(just put in our records now) where you can do it, but a LOT of people
can't do their own DNS so can't implement it. The view has been proposed
that such domains would be "punished" by being either scored more highly
for spam or whatever, but I think this will prove to be unworkable - too
many of them.

I can see a lot of mail server developers being really tempted to write a
mail server that can be configured to reject all mail from domains that
don't have SPF records. That would result in a bit of carnage for their
support personnel.

We got around this quite successfully in our mail server by using a
combination of SPF-like tests, and some more specific hybrid-style ones
with a comprehensive exception list. We are currently achieving a high
rejection accuracy without using SPF records (customer reports indicate
about 99% accuracy, improving using the exception list for senders with no
reverse DNS). So I think there is a good case for such a system, and the
exceptions point to cases where ISPs need to clean up their DNS, rather
than cases where individual companies or domain owners need to configure
theirs - a few orders of magnitude smaller a problem...

Adrien


>Roger
>
>-------
>To unsubscribe, change your address, or temporarily deactivate your
>subscription,
>please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

------------------------------------------------------------------------
Adrien de Croy Qbik New Zealand Limited
The makers of WinGate, and WinGate VPN.
http://www.qbik.com/
------------------------------------------------------------------------
check out the new WinGate website http://www.wingate.com
------------------------------------------------------------------------

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

At 30/05/2004 01:47, Michael R. Brumm wrote:

>A real issue might be "Are there a lot of MTAs that do not use a FQDN in
>HELO when sending a DSN?" because these MTAs will eventually find their
>DSNs ignored by the rest of the Internet.

We seem to get quite a few, but admittedly not many of these are valid
senders (just enough valid ones to stop us putting a blanket ban on it
unfortunately).... the number seems to be growing though, esp PHP scripts
for some reason seem to like more and more nowadays to present the FQDN or
IP address of whoever they are connecting TO instead of their own.

Adrien
------------------------------------------------------------------------
Adrien de Croy Qbik New Zealand Limited
The makers of WinGate, and WinGate VPN.
http://www.qbik.com/
------------------------------------------------------------------------
check out the new WinGate website http://www.wingate.com
------------------------------------------------------------------------

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

> -----Original Message-----
> From: owner-spf-devel@v2.listbox.com
> [mailto:owner-spf-devel@v2.listbox.com]On Behalf Of Adrien de Croy
> Sent: 30 May 2004 09:24
> To: spf-devel@v2.listbox.com; spf-devel@v2.listbox.com
> Subject: RE: [spf-devel] blank return path
>
>
> At 30/05/2004 01:47, Michael R. Brumm wrote:
>
> >A real issue might be "Are there a lot of MTAs that do not use a FQDN in
> >HELO when sending a DSN?" because these MTAs will eventually find their
> >DSNs ignored by the rest of the Internet.
>
> We seem to get quite a few, but admittedly not many of these are valid
> senders (just enough valid ones to stop us putting a blanket ban on it
> unfortunately).... the number seems to be growing though, esp PHP scripts
> for some reason seem to like more and more nowadays to present the FQDN or
> IP address of whoever they are connecting TO instead of their own.

The SPF page lists "make your users authenticate with SASL" as a
recommendation, which I wholeheartedly agree with.

Any mail that comes into my servers that isn't authenticated and gives
the address or FQDN of the server in question is automatically rejected
as spam - it's a violation of the specs, and the chances of a non-authed
user sending mail from the server itself is absolutely minimal.

One thing I thought, actually, was that SPF is checking on the HELO/EHLO
and MAIL FROM commands - but why couldn't it check the IP address
and/or domain name of the connecting server? You can always recover
the address of the "other end" with sockets. Log from my rejected mail
list yesterday:

2004-05-29 02:35:01 H=(80.177.236.66) [211.187.21.212] F=<Gaines@ped.uas.lul.se> rejected RCPT<matt@genesi.co.uk>: HELO of this
systems ip
2004-05-29 02:37:47 H=chello213047155046.5.graz.surfer.at [213.47.155.46] F=<muziuaqraptk@snogtastic.co.uk> rejected RCPT
<matt@genesi.co.uk>: Not authorized by SPF

.. HELO/EHLO gives one thing, but Exim does know what the real address
is, why can't it pass this back to SPF and have it check that too?

--
Matt Sealey <matt@genesi.co.uk>
Genesi, Manager, Developer Relations

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

>One thing I thought, actually, was that SPF is checking on the HELO/EHLO
>and MAIL FROM commands - but why couldn't it check the IP address
>and/or domain name of the connecting server?

Are you suggesting that an IP address's PTR be used? That could cause insane SPF evaluation.

Example:
68.167.225.114 is one of my MXs for the domain "michaelbrumm.com". It says:
"HELO smtp.michaelbrumm.com"

It's PTR record (reverse DNS of 68.167.225.114) is:
"h-68-167-225-114.phndaz91.covad.net"

Using the PTR would cause covad.net's SPF record to be evaluated instead of mine. Even if my server said "HELO" (no FQDN) or "HELO 68.167.225.114" during a DSN, I'd rather have it evaluate as "unknown" or "none" than use covad.net's SPF records and end up with a "fail".

Michael R. Brumm

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Sun, May 30, 2004 at 08:18:25PM +1200, Adrien de Croy wrote:
| Customers of ISPs who use dynamic IP addresses, and don't host their own
| DNS and don't host their own mail servers, yet deliver direct to MX from
| their dynamic IPs. So the MX never matches the deliverer of mail from that
| domain. Since DNS for that domain is also hosted by the ISP, this person
| can't implement SPF, unless their ISP does it for them, and ties in the IPs
| with the currently assigned IP for their account. If they don't have the
| means to do this, then it's not going to happen.

Markets respond to environmental change. SPF is an
environmental change. DNS service providers have already
responded by allowing users to configure TXT records. I'm
counting on the above scenario to disappear due to further
adaptation.

| I can see a lot of mail server developers being really tempted to write a
| mail server that can be configured to reject all mail from domains that
| don't have SPF records. That would result in a bit of carnage for their
| support personnel.

If we ever reach that horizon, I expect the fallback default
for domains that don't publish SPF records will be "a/24
mx/24 ptr -all" rather than just an "-all".

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

A *VERY* good point.. I stand corrected :)

--
Matt Sealey <matt@genesi.co.uk>
Genesi, Manager, Developer Relations

> -----Original Message-----
> From: owner-spf-devel@v2.listbox.com
> [mailto:owner-spf-devel@v2.listbox.com]On Behalf Of Michael R. Brumm
> Sent: 30 May 2004 11:42
> To: spf-devel@v2.listbox.com
> Subject: RE: [spf-devel] blank return path
>
>
> >One thing I thought, actually, was that SPF is checking on the HELO/EHLO
> >and MAIL FROM commands - but why couldn't it check the IP address
> >and/or domain name of the connecting server?
>
> Are you suggesting that an IP address's PTR be used? That could cause insane SPF evaluation.
>
> Example:
> 68.167.225.114 is one of my MXs for the domain "michaelbrumm.com". It says:
> "HELO smtp.michaelbrumm.com"
>
> It's PTR record (reverse DNS of 68.167.225.114) is:
> "h-68-167-225-114.phndaz91.covad.net"
>
> Using the PTR would cause covad.net's SPF record to be evaluated instead of mine. Even if my server said "HELO" (no FQDN)
> or "HELO 68.167.225.114" during a DSN, I'd rather have it evaluate as "unknown" or "none" than use covad.net's SPF
> records and end up with a "fail".
>
> Michael R. Brumm
>
> -------
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In keeping with usual rude practice, I'm going to share my
thoughts on this before reading the ninety-odd replies from others
who have likely done something similar.

In my opinion, blank return path handling is one of the ways in
which SMTP is too trusting and can be improved. As an author
of a forwarding system, when to accept blank return path is an
open question.

Ideally, blank return path only appears on legitimate bounce
messages.

Marking every outgoing message with a unique return path, constructed
in any of a variety of ways, and only accepting the blank return path
when the blank return path is trying to deliver to one of the
valid recent return paths, is one way to verify the legitimacy of
incoming bounces.



Adrien de Croy wrote:
...
> Since RFC 2821 mandates that any MTA must accept mail with a blank
> return path, therefore there is no domain to check with SPF, and thence
> the spam floods in.
>
> We see this empirically with our server. Shutting off blank return
> paths reduces our spam intake dramatically.
>
> However people who choose to administratively ban blank return paths
> simply get blacklisted on various lists of dubious merit for
> non-compliance.
>
> I found a discussion of blank return paths conspicuously absent from the
> draft SPF spec I read, although it makes reference to other policy
> decisions of the receiver.

--
davidnicol@pay2send.com
"There's a fine line between participation and mockery" -- Scott Adams

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com