What are the IPs that sends mail for a domain?

[Franck Martin-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I recently encountered the following question/problems.

I have a mail server and one of my users complains he is not receiving emails from a domain. How do I find if I have blocked the domain from sending to my server. Meaning, knowing the domain name of the sender, how do I find the IPs from where the mail could be sent from. It seems that SPF is the only tool to provide that answer?

In another related problem, which is linked to IPv6 and RBL. Buidling an IPv6 RBL could lead to a huge database. Sure you can alleviate by using "wildcards", but why not use the reverse DNS resolution to add a TXT record associated to the IP to indicate the IP is the one of a mail server? So any IP that does not have this record would be blocked for SMTP. As IPv6 is not used for SMTP (or barely), this could be made mandatory for IPv6 and optional for IPv4. An MUA could talk to an MTA on port 25 because we know the the etwork range of the MUA or the alternative is to use the new mail submit port.

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>How do I find if I have blocked the domain from sending to my server. Meaning, knowing the
>domain name of the sender, how do I find the IPs from where the mail could be sent from. It
>seems that SPF is the only tool to provide that answer?

Unless you have previous mail from the domain, I would agree SPF is your best bet.


>In another related problem, which is linked to IPv6 and RBL. Buidling an IPv6 RBL could lead
>to a huge database. Sure you can alleviate by using "wildcards", but why not use the reverse
>DNS resolution to add a TXT record associated to the IP to indicate the IP is the one of a
>mail server? So any IP that does not have this record would be blocked for SMTP.

We've had a variety of proposals to identify mail client hosts.  See http://mipassoc.org/csv/

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[sm-7]

At 15:20 16-06-2009, Franck Martin wrote:
>I have a mail server and one of my users complains he is not
>receiving emails from a domain. How do I find if I have blocked the
>domain from sending to my server. Meaning, knowing the domain name
>of the sender, how do I find the IPs from where the mail could be
>sent from. It seems that SPF is the only tool to provide that answer?

You can use the mail log to track down whether you blocked the
domain.  The information might not be available if you are blocking
by IP address.  You could also contact the postmaster at the other end.

Regards,
-sm  

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Johnson-13]

John Levine wrote:
>> How do I find if I have blocked the domain from sending to my server. Meaning, knowing the
>> domain name of the sender, how do I find the IPs from where the mail could be sent from. It
>> seems that SPF is the only tool to provide that answer?
>>    
>
> Unless you have previous mail from the domain, I would agree SPF is your best bet.
>  
   I would also add that if your e-mail is important, having good
logging on your server
   of when the domain or ip was blocked can help speed up rectifying the
problem.

   Yes, it's after the block occurred - but so was the complaint.


_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Daniel Feenberg]

On Wed, 17 Jun 2009, Franck Martin wrote:

> I recently encountered the following question/problems.
>
> I have a mail server and one of my users complains he is not receiving
> emails from a domain. How do I find if I have blocked the domain from
> sending to my server. Meaning, knowing the domain name of the sender,
> how do I find the IPs from where the mail could be sent from. It seems
> that SPF is the only tool to provide that answer?
>
> In another related problem, which is linked to IPv6 and RBL. Buidling an
> IPv6 RBL could lead to a huge database. Sure you can alleviate by using
> "wildcards", but why not use the reverse DNS resolution to add a TXT
> record associated to the IP to indicate the IP is the one of a mail
> server? So any IP that does not have this record would be blocked for
> SMTP. As IPv6 is not used for SMTP (or barely), this could be made
> mandatory for IPv6 and optional for IPv4. An MUA could talk to an MTA on
> port 25 because we know the the etwork range of the MUA or the
> alternative is to use the new mail submit port.

I predict that no significant amount of mail ever originates from IPV6.
Because it would be impossible to maintain a DNSBL for IPV6, I expect that
enough sites will decline all IPV6 mail that it won't pay to send from it.
Consider that because a spammer could (spoof) a different IPV6 address for
every message, even a different 48 bit block for every messages, MTAs will
be left with only content analysis for spam blocking. I don't expect IPV4s
will ever be so scarce that enough MTAs will start using them out of
necessity - ISPs will give each customer 4 IPV4 addresses with their
million address IPV6 range, and customers will use those 4 addresses for
the things that really need IPV4 - such as internet facing MTAs.

Consider also the difficulty facing the first IPV6 only MTA. It's
connectivity will be very low, even compared to the worst possible
allocation of a former spammer block in IPV4. It is one thing to put up a
little used IPV6 web site - there isn't much of a penalty for adding IPV6
to IPV4. And eventually some special purpose websites will be IPV6 only,
those that know their clients are IPV6 only. But there isn't any point in
a public-facing IPV6 MTA without an IPV4 alternative. And since the IPV4
alternative can serve the IPV6 clients just as well, it will never be very
usefull to add IPV6 support.

This is a prediction, not a prescription.

Daniel Feenberg



>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On Jun 16, 2009, at 3:55 PM, John Levine wrote:

>> How do I find if I have blocked the domain from sending to my  
>> server. Meaning, knowing the domain name of the sender, how do I  
>> find the IPs from where the mail could be sent from. It seems that  
>> SPF is the only tool to provide that answer?
>
> Unless you have previous mail from the domain, I would agree SPF is  
> your best bet.

This is not your only bet.  Many SPF records include the term MX and,  
when not found, even default to using MX/24.

>> In another related problem, which is linked to IPv6 and RBL.  
>> Buidling an IPv6 RBL could lead to a huge database. Sure you can  
>> alleviate by using "wildcards", but why not use the reverse DNS  
>> resolution to add a TXT record associated to the IP to indicate the  
>> IP is the one of a mail server? So any IP that does not have this  
>> record would be blocked for SMTP.
>
> We've had a variety of proposals to identify mail client hosts.  See http://mipassoc.org/csv/

The CSV effort proved most providers do not want their MTAs identified  
as belonging to them, even when it could improve email acceptance.  
This might be especially true now after their support staff has been  
reduced.

Reverse DNS is already causing a large amount of resources to be  
wasted by the shabby state of the reverse name space.  Incorrectly  
configured RFC 2317 delegation, and many non-functional servers are  
causing MTAs to rapidly become resource limited when making reverse  
checks.   In addition, when your customers conduct business with Asia,  
they may not be happy to find email is being lost as a result of  
geographic differences of opinion about the role that reverse DNS  
might play with email.

IMHO, all outbound MTAs should be required to return CVS records for  
their EHLO name and offer MX records for their inbound.  A mandate  
that required MX (inbound) or CVS (outbound) records would greatly  
help in identifying non-abusive email sources against a backdrop of  
hundreds of millions of bot-net controlled drones spewing email.  
Systems may soon use ACLs as a means to white-list safe MTAs.  Perhaps  
the world is a few years from having to go to that extreme.

-Doug



_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote:
> IMHO, all outbound MTAs should be required to return CVS records for  
> their EHLO name and offer MX records for their inbound.

Doug, are you sure that's what you meant to say? The sentence is a bit
ambiguous. Are you really saying any host that sends mail (is an SMTP
client) MUST also host an listed SMTP server?

--lyndon

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Bill Cole-2]

Lyndon Nerenberg wrote, On 6/16/09 9:55 PM:
> On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote:
>> IMHO, all outbound MTAs should be required to return CVS records for
>> their EHLO name and offer MX records for their inbound.
>
> Doug, are you sure that's what you meant to say? The sentence is a bit
> ambiguous. Are you really saying any host that sends mail (is an SMTP
> client) MUST also host an listed SMTP server?

I can't testify to what he meant, but I think what he is actually saying is
that if you have a machine that says "EHLO some.name" then there should be
both a MX record for some.name and a SRV record for _client._smtp.some.name
(i.e. a CSV/CSA record).

That doesn't mean requiring inbound SMTP on every outbound, it means
requiring an affirmation in DNS that a name can be used in EHLO by a
particular IP address and a way to get mail to the responsible party for the
machine(s) using that name in EHLO. This is an admirable goal. A weaker goal
would be to get people running non-spamming mail servers to follow the
existing accepted standard of using a valid resolvable FQDN in EHLO.


_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Franck Martin-3]

Knowing that mail servers are not deployed on IPv6, what would it take to make all these requirements mandatory for IPv6 and start with a better infrastructure than on IPv4?

----- Original Message -----
From: "Bill Cole" <asrg3@...>
To: "Anti-Spam Research Group - IRTF" <asrg@...>
Sent: Tuesday, 16 June, 2009 8:27:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [Asrg] What are the IPs that sends mail for a domain?

Lyndon Nerenberg wrote, On 6/16/09 9:55 PM:
> On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote:
>> IMHO, all outbound MTAs should be required to return CVS records for
>> their EHLO name and offer MX records for their inbound.
>
> Doug, are you sure that's what you meant to say? The sentence is a bit
> ambiguous. Are you really saying any host that sends mail (is an SMTP
> client) MUST also host an listed SMTP server?

I can't testify to what he meant, but I think what he is actually saying is
that if you have a machine that says "EHLO some.name" then there should be
both a MX record for some.name and a SRV record for _client._smtp.some.name
(i.e. a CSV/CSA record).

That doesn't mean requiring inbound SMTP on every outbound, it means
requiring an affirmation in DNS that a name can be used in EHLO by a
particular IP address and a way to get mail to the responsible party for the
machine(s) using that name in EHLO. This is an admirable goal. A weaker goal
would be to get people running non-spamming mail servers to follow the
existing accepted standard of using a valid resolvable FQDN in EHLO.


_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Bill Cole-2]

Franck Martin wrote, On 6/16/09 6:20 PM:
> I recently encountered the following question/problems.
>
> I have a mail server and one of my users complains he is not receiving
> emails from a domain. How do I find if I have blocked the domain from
> sending to my server. Meaning, knowing the domain name of the sender,
> how do I find the IPs from where the mail could be sent from.

There is no reliable way to do so.

> It seems
> that SPF is the only tool to provide that answer?

Only partially. SPF cannot be considered reliable, since not all domains
publish records and some publish inaccurate records.

There have been other proposed approaches that may have some deployment:

CSV/CSA: http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.html
DRIP: http://tools.ietf.org/html/draft-brand-drip-02

> In another related problem, which is linked to IPv6 and RBL. Buidling an
> IPv6 RBL could lead to a huge database. Sure you can alleviate by using
> "wildcards", but why not use the reverse DNS resolution to add a TXT
> record associated to the IP to indicate the IP is the one of a mail
> server? So any IP that does not have this record would be blocked for
> SMTP. As IPv6 is not used for SMTP (or barely), this could be made
> mandatory for IPv6 and optional for IPv4. An MUA could talk to an MTA on
> port 25 because we know the the etwork range of the MUA or the
> alternative is to use the new mail submit port.

Similar proposals have been made before, and I'm pretty sure one such has
been made on this list although I can't find proof of that at present.

There's always some degree of resistance to putting information into the
reverse zone because it is frequently under different control than related
forward zones and can be a chore to get set or changed. There are also
concerns about loading up new sorts of records into the reverse zone because
it is a simpler tree that has traditionally had light query volume, and the
existing systems may not be prepared to handle an extra query down the
reverse tree for every SMTP connection.

That said, I think that adding DNS records that map specific network
addresses to their legitimate behaviors in a generalized model would be a
positive advance.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[der Mouse-3]

> Knowing that mail servers are not deployed on IPv6,

They're not?  Mine has been for years.  netbsd.org's MX host is
v6-reachable and I think it has been for years too.  freebsd.org's
ditto.  And two of icann.org's five MX hosts are v6-reachable too and
probably have been for quite a while.

Where did you get the idea mailservers aren't deployed on v6?

/~\ The ASCII  Mouse
\ / Ribbon Campaign
 X  Against HTML mouse@...
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Franck Martin-3]

well, I have still enough fingers to count them....

----- Original Message -----
From: "der Mouse" <mouse@...>
To: "Anti-Spam Research Group - IRTF" <asrg@...>
Sent: Tuesday, 16 June, 2009 8:58:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [Asrg] What are the IPs that sends mail for a domain?

> Knowing that mail servers are not deployed on IPv6,

They're not?  Mine has been for years.  netbsd.org's MX host is
v6-reachable and I think it has been for years too.  freebsd.org's
ditto.  And two of icann.org's five MX hosts are v6-reachable too and
probably have been for quite a while.

Where did you get the idea mailservers aren't deployed on v6?

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Bill Cole-2]

Franck Martin wrote, On 6/16/09 11:33 PM:
> Knowing that mail servers are not deployed on IPv6, what would it take to
> make all these requirements mandatory for IPv6 and start with a better
> infrastructure than on IPv4?

How do you make anything mandatory on the net?

RFC 821 is one of a handful of Internet Standards, and it is violated
routinely by spammers and non-spammers for no better reason than that they
never bothered to read it. That is possible because the major MTA's are
functional when misconfigured (e.g. with a bogus name for EHLO/HELO use) and
by default tolerate clients which violate standards.

The only way anything can be functionally mandatory for email transport is
if major MTA's will not work unless configured to comply and by default will
not interoperate with clients that do not comply. RFC's are great, but they
do not enforce themselves. If the big freemail providers and sites running
Sendmail, Exchange, and Postfix generally accept mail from non-compliant
clients, there will be a lot of non-compliant clients. To make good behavior
mandatory, bad behavior has to break with enough frequency that it's easier
to comply than negotiate exemptions.

> ----- Original Message ----- From: "Bill
> Cole"<asrg3@...> To: "Anti-Spam Research Group -
> IRTF"<asrg@...> Sent: Tuesday, 16 June, 2009 8:27:27 PM GMT +01:00
> Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Asrg]
> What are the IPs that sends mail for a domain?
>
> Lyndon Nerenberg wrote, On 6/16/09 9:55 PM:
>> On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote:
>>> IMHO, all outbound MTAs should be required to return CVS records for
>>> their EHLO name and offer MX records for their inbound.
>> Doug, are you sure that's what you meant to say? The sentence is a bit
>> ambiguous. Are you really saying any host that sends mail (is an SMTP
>> client) MUST also host an listed SMTP server?
>
> I can't testify to what he meant, but I think what he is actually saying
> is that if you have a machine that says "EHLO some.name" then there
> should be both a MX record for some.name and a SRV record for
> _client._smtp.some.name (i.e. a CSV/CSA record).
>
> That doesn't mean requiring inbound SMTP on every outbound, it means
> requiring an affirmation in DNS that a name can be used in EHLO by a
> particular IP address and a way to get mail to the responsible party for
> the machine(s) using that name in EHLO. This is an admirable goal. A
> weaker goal would be to get people running non-spamming mail servers to
> follow the existing accepted standard of using a valid resolvable FQDN in
> EHLO.
>
>
> _______________________________________________ Asrg mailing list
> Asrg@... http://www.irtf.org/mailman/listinfo/asrg
> _______________________________________________ Asrg mailing list
> Asrg@... http://www.irtf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Franck Martin-3]

Sure, it is the the be strict in what you send, lenient in what you receive.

If we don't specify some RFC/BCP to specify how SMTP over IPv6 should be negotiated, then no one will follow.

We could say something like all emails on IPv6 must have a DKIM signature, have RDNS helo, etc... as there is not much of an implementation with IPv6, there is a chance for these practices to be adopted from day one...


----- Original Message -----
From: "Bill Cole" <asrg3@...>
To: "Anti-Spam Research Group - IRTF" <asrg@...>
Sent: Tuesday, 16 June, 2009 10:14:02 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [Asrg] What are the IPs that sends mail for a domain?

Franck Martin wrote, On 6/16/09 11:33 PM:
> Knowing that mail servers are not deployed on IPv6, what would it take to
> make all these requirements mandatory for IPv6 and start with a better
> infrastructure than on IPv4?

How do you make anything mandatory on the net?

RFC 821 is one of a handful of Internet Standards, and it is violated
routinely by spammers and non-spammers for no better reason than that they
never bothered to read it. That is possible because the major MTA's are
functional when misconfigured (e.g. with a bogus name for EHLO/HELO use) and
by default tolerate clients which violate standards.

The only way anything can be functionally mandatory for email transport is
if major MTA's will not work unless configured to comply and by default will
not interoperate with clients that do not comply. RFC's are great, but they
do not enforce themselves. If the big freemail providers and sites running
Sendmail, Exchange, and Postfix generally accept mail from non-compliant
clients, there will be a lot of non-compliant clients. To make good behavior
mandatory, bad behavior has to break with enough frequency that it's easier
to comply than negotiate exemptions.

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>If we don't specify some RFC/BCP to specify how SMTP over IPv6 should be
>negotiated, then no one will follow.

The IETF is amazingly resistant to making v6 SMTP different from v4 SMTP
in any way.

In particular, I suggested that they not have a rule for fallback to
AAAA in the absence of MX.  The rationale is straightforward: most
hosts with AAAA (and indeed A) records are not mail servers, people
need to add new DNS records anyway for v6 so the incremental effort to
install MX records is quite small, and it'll make mail more reliable
by making it easier to tell when a domain doesn't receive mail.  They
all said too late, there are already a handful of v6 mail hosts.
Sigh.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 16 June 2009 17:24:03 -0700 Douglas Otis <dotis@...> wrote:

>
> The CSV effort proved most providers do not want their MTAs identified as
> belonging to them, even when it could improve email acceptance.  This
> might be especially true now after their support staff has been reduced.

It'll probably depend on how much difference it makes to email acceptance.
The harder it is to deliver email without some assurance that the sender
isn't spoofed, the better.

> Reverse DNS is already causing a large amount of resources to be wasted
> by the shabby state of the reverse name space.  Incorrectly configured
> RFC 2317 delegation, and many non-functional servers are causing MTAs to
> rapidly become resource limited when making reverse checks.   In
> addition, when your customers conduct business with Asia, they may not be
> happy to find email is being lost as a result of geographic differences
> of opinion about the role that reverse DNS might play with email.
>
> IMHO, all outbound MTAs should be required to return CVS records for
> their EHLO name and offer MX records for their inbound.  A mandate that
> required MX (inbound) or CVS (outbound) records would greatly help in
> identifying non-abusive email sources against a backdrop of hundreds of
> millions of bot-net controlled drones spewing email.  Systems may soon
> use ACLs as a means to white-list safe MTAs.  Perhaps the world is a few
> years from having to go to that extreme.

It's not a binary thing, though.

> -Doug



--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 17 June 2009 01:14:02 -0400 Bill Cole <asrg3@...>
wrote:

> Franck Martin wrote, On 6/16/09 11:33 PM:
>> Knowing that mail servers are not deployed on IPv6, what would it take to
>> make all these requirements mandatory for IPv6 and start with a better
>> infrastructure than on IPv4?
>
> How do you make anything mandatory on the net?
>
> RFC 821 is one of a handful of Internet Standards, and it is violated
> routinely by spammers and non-spammers for no better reason than that
> they never bothered to read it.

Well, parts of it are. The rest is mandatory for the purely practical
reason that you can't deliver email without obeying those parts. For
example, to send email to someone, it IS mandatory to give their email
address in a RCPT command.

How do you make other parts mandatory? Well, it's a long and arduous task,
but the steps look like this:

1. make sure that the bulk of client MTA's behave correctly
2. start basing reputation scores on failure to respect the standard
    this can take several forms: refusal to whitelist non-compliant
senders, incrementing spam scores, rejecting mail

As the deliverability of non-compliant email drops, the proportion of
senders complying will increase. A virtuous circle takes us to a world
where everybody is compliant. Eventually, even the spammers comply. So,
it's just an arms race in some cases, but in other cases we may have
regained some real value. For example, if respecting SPF were universal
(with fixes for forwarding), then backscatter would not be a problem.

> That is possible because the major MTA's
> are functional when misconfigured (e.g. with a bogus name for EHLO/HELO
> use) and by default tolerate clients which violate standards.
>
> The only way anything can be functionally mandatory for email transport
> is if major MTA's will not work unless configured to comply and by
> default will not interoperate with clients that do not comply. RFC's are
> great, but they do not enforce themselves. If the big freemail providers
> and sites running Sendmail, Exchange, and Postfix generally accept mail
> from non-compliant clients, there will be a lot of non-compliant clients.
> To make good behavior mandatory, bad behavior has to break with enough
> frequency that it's easier to comply than negotiate exemptions.
>
>
>> ----- Original Message ----- From: "Bill
>> Cole"<asrg3@...> To: "Anti-Spam Research Group -
>> IRTF"<asrg@...> Sent: Tuesday, 16 June, 2009 8:27:27 PM GMT +01:00
>> Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Asrg]
>> What are the IPs that sends mail for a domain?
>>
>> Lyndon Nerenberg wrote, On 6/16/09 9:55 PM:
>>> On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote:
>>>> IMHO, all outbound MTAs should be required to return CVS records for
>>>> their EHLO name and offer MX records for their inbound.
>>> Doug, are you sure that's what you meant to say? The sentence is a bit
>>> ambiguous. Are you really saying any host that sends mail (is an SMTP
>>> client) MUST also host an listed SMTP server?
>>
>> I can't testify to what he meant, but I think what he is actually saying
>> is that if you have a machine that says "EHLO some.name" then there
>> should be both a MX record for some.name and a SRV record for
>> _client._smtp.some.name (i.e. a CSV/CSA record).
>>
>> That doesn't mean requiring inbound SMTP on every outbound, it means
>> requiring an affirmation in DNS that a name can be used in EHLO by a
>> particular IP address and a way to get mail to the responsible party for
>> the machine(s) using that name in EHLO. This is an admirable goal. A
>> weaker goal would be to get people running non-spamming mail servers to
>> follow the existing accepted standard of using a valid resolvable FQDN in
>> EHLO.
>>
>>
>> _______________________________________________ Asrg mailing list
>> Asrg@... http://www.irtf.org/mailman/listinfo/asrg
>> _______________________________________________ Asrg mailing list
>> Asrg@... http://www.irtf.org/mailman/listinfo/asrg
>
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg

--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 17 June 2009 08:51:06 +0000 John Levine <johnl@...> wrote:

>> If we don't specify some RFC/BCP to specify how SMTP over IPv6 should be
>> negotiated, then no one will follow.
>
> The IETF is amazingly resistant to making v6 SMTP different from v4 SMTP
> in any way.
>
> In particular, I suggested that they not have a rule for fallback to
> AAAA in the absence of MX.  The rationale is straightforward: most
> hosts with AAAA (and indeed A) records are not mail servers, people
> need to add new DNS records anyway for v6 so the incremental effort to
> install MX records is quite small, and it'll make mail more reliable
> by making it easier to tell when a domain doesn't receive mail.  They
> all said too late, there are already a handful of v6 mail hosts.
> Sigh.

But, do they have MX records? If yes, there's not a problem. Do you receive
any email from them? If no, there's not a problem.

If a good chunk of the world implemented the rule that you've suggested
(perhaps "*.ac.uk" or  "*.gov" domains, or just gmail), then we'd be in a
good place. It might not be too late for some leadership initiative to
actually make a difference outside the IETF.



>
> R's,
> John
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg



--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 16 June 2009 19:17:41 -0400 Daniel Feenberg <feenberg@...> wrote:

>
> I predict that no significant amount of mail ever originates from IPV6.
> Because it would be impossible to maintain a DNSBL for IPV6, I expect
> that enough sites will decline all IPV6 mail that it won't pay to send
> from it.
> Consider that because a spammer could (spoof) a different IPV6 address
> for every message, even a different 48 bit block for every messages, MTAs
> will be left with only content analysis for spam blocking.

Which is why reputation services need to be based on sender domains, not IP
addresses. Users can then whitelist as required, and use of IP
addresses/domains without good positive reputation won't work very well.

The advantage of IPV6, of course, is that you'll never have to share an IP
address with someone with poor reputation.

> I don't expect
> IPV4s will ever be so scarce that enough MTAs will start using them out
> of necessity - ISPs will give each customer 4 IPV4 addresses with their
> million address IPV6 range, and customers will use those 4 addresses for
> the things that really need IPV4 - such as internet facing MTAs.



--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Dotzero]

On Tue, Jun 16, 2009 at 6:20 PM, Franck Martin<franck@...> wrote:
> I recently encountered the following question/problems.
>
> I have a mail server and one of my users complains he is not receiving
> emails from a domain. How do I find if I have blocked the domain from
> sending to my server. Meaning, knowing the domain name of the sender, how do
> I find the IPs from where the mail could be sent from. It seems that SPF is
> the only tool to provide that answer?
>

One approach that might help you is to go to senderscore.org (from
ReturnPath). Register for a free account and then enter in the domain
name. For example, when I enter in avonsys.com it shows me that there
is one IP address sending mail for that domain - 76.203.192.33 with a
hostname of adsl-76-203-192-33.dsl.rcsntx.sbcglobal.net.

Hope this helps.

> In another related problem, which is linked to IPv6 and RBL. Buidling an
> IPv6 RBL could lead to a huge database. Sure you can alleviate by using
> "wildcards", but why not use the reverse DNS resolution to add a TXT record
> associated to the IP to indicate the IP is the one of a mail server? So any
> IP that does not have this record would be blocked for SMTP. As IPv6 is not
> used for SMTP (or barely), this could be made mandatory for IPv6 and
> optional for IPv4. An MUA could talk to an MTA on port 25 because we know
> the the etwork range of the MUA or the alternative is to use the new mail
> submit port.
>
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg
>
>

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg