@.eu Not Allowed As Email Address?

[Fantasma]

Cannot create or modify a client account and use a .EU address -- how do you fix?

[Paul]

Does the domain have a valid MX record? Can your server resolve DNS properly? Blesta simply checks that a valid MX record exist for a given domain within an email address. If it doesn't have an MX record, it cannot receive email and fails validation.

[Max]

  On 8/18/2015 at 5:16 AM, Paul said:

If it doesn't have an MX record, it cannot receive email and fails validation.

 

While it is customary to have one, it is not a requirement, if you only have one mail server.

Foreign mail servers wanting to deliver to your domain will simply use the A record if there is no MX.

 

RFC 5321 SMTP

 

  Quote

The lookup first attempts to locate an MX record associated with the

name. If a CNAME record is found, the resulting name is processed as

if it were the initial name. If a non-existent domain error is

returned, this situation MUST be reported as an error. If a

temporary error is returned, the message MUST be queued and retried

later (see Section 4.5.4.1). If an empty list of MXs is returned,

the address is treated as if it was associated with an implicit MX

RR, with a preference of 0, pointing to that host. If MX records are

present, but none of them are usable, or the implicit MX is unusable,

this situation MUST be reported as an error.

[Paul]

Interesting, I'm surprised I have never heard of this. https://tools.ietf.org/html/rfc5321#section-5.1

 

I'm assuming then that the address you are having trouble with has no MX record, but there is a valid A record, and the domain does receive mail? If we make a change, we should be clear about what we are changing. So, in this case, we should assume if their is no MX record, but there is an A or AAAA record, then we should accept the address?

 

It may be possible that a domain has no A record, but has an MX, and it's also possible that the domain have no A record, but resolve to an IPv6 address with AAAA. So, I believe we would want to check the MX, and if there is no record, check A, then AAAA, and if no record is found in any case, reject the address.

 

I have to think that it's a bad idea not to have a valid MX record and to rely on this RFC, given that many spam filters and other devices are likely to check the presence of a valid MX record. For example: (from http://www.watchguard.com/help/docs/wsm/xtm_11/en-US/index.html#cshid=en-US/multiwan/mx_record_c.html)

 

  Quote

Before the receiving server continues the transaction, it makes a DNS query to see whether a valid MX record for the sender’s domain exists. If the domain has no valid DNS MX record, then the sender is not valid and the receiving server rejects it as a spam source.

 

Watchguard makes spam and network firewalls and their documentation seems to indicate that they rely solely on the MX record. I suspect this may be fairly prevalent.

[Max]

  On 8/19/2015 at 5:56 PM, Paul said:

Interesting, I'm surprised I have never heard of this. https://tools.ietf.org/html/rfc5321#section-5.1

 

I'm assuming then that the address you are having trouble with has no MX record, but there is a valid A record, and the domain does receive mail? If we make a change, we should be clear about what we are changing. So, in this case, we should assume if their is no MX record, but there is an A or AAAA record, then we should accept the address?

 

It may be possible that a domain has no A record, but has an MX, and it's also possible that the domain have no A record, but resolve to an IPv6 address with AAAA. So, I believe we would want to check the MX, and if there is no record, check A, then AAAA, and if no record is found in any case, reject the address.

 

 

 

That would do as an intial check.

Think you should also support verifying the entire e-mail address by sending an e-mail with activation code/link to it.

Some registries require that you have verified the e-mail address of the customer when registering domains.

 

 

 

 

  Quote

Watchguard makes spam and network firewalls and their documentation seems to indicate that they rely solely on the MX record. I suspect this may be fairly prevalent.

 

Not sure about the prevalence.

Have my doubts about what else is being said on that page as well:

 

 

  Quote

Many anti-spam solutions, including those used by most major ISP networks and web mail providers such as AOL, MSN, and Yahoo!, use a reverse MX lookup procedure. Different variations of the reverse lookup are used, but the goals are the same: the receiving server wants to verify that the email it receives does not come from a spoofed or forged sending address, and that the sending server is an authorized mail exchanger for that domain.

 

 

Ah, state of the art spam filtering from the century that AOL still provided free frisbees. 

 

Checking MX records, to see if the sending server is authorized for that domain?

How is that ever going to work?

Major providers like Gmail use server names like mail-lb0-f173.google.com for their outbound e-mail, which are certainly NOT mentioned in the MX records for gmail.com nor google.com.

It is more common to use SPF for this purpose instead. But even that is too unreliable as sole indicator to filter e-mail, as it causes way too many false positives with e-mail forwarding and mailing list...