Re: A possible looming problem with DMARC

Mark Sawle <mark@...> wrote:

> At the moment such validation requires an opt-in from the domain owner.
> Records are added to the DNS that list the mail servers allowed to send
> mail from that domain and the policy to take with mail that doesn't appear
> to come from one of those servers. Yahoo has done exactly that so mail
> from Yahoo addresses can now only be sent via Yahoo mail servers.

Can I just say at the start how grateful I am for your explanation - the
most detailed, thorough and understandable one I've seen anywhere so far.  


> This will only become an issue for other domains if the administrators of
> those domains also add their own DNS records to restrict which servers can
> send mail from those domains. If you're the domain owner and you add no
> such records then you shouldn't have any problem with your mail being
> rejected as the default is to accept all mail if no records exist. Anybody
> whose email requirements are sufficently advanced so as to need to be able
> to send mail through other mail servers should really register themselves
> a domain so they have full control over such policies.

So, for me to send mail from addresses 'belonging' to a choir website, it
should just work.  If in future it doesn't (eg if some recipient system was
to insist on DNS records naming valid servers in use) then I should be able
to fix that by updating the choir website's DNS to specify that the outbound
mail servers I wish to use are allowed to send those mails...



>> It looks as if in future I may need to send sets of emails out via
>> different SMTP servers.  This will be
>> 
>>   a) nigh on impossible unless MP has a way for me to associate a 
>>      specific account with each of my named identities
>
> MPro can actually do this. Each account can have a default identity
> associated with it which tells MPro to use that account for mail sent from
> that identity. 

But...

> What's missing of course is that you can't have more than one identity
> linked to an account

That's my problem (or would be if what you wrote at the start hadn't made
this much less likely to be an issue).  I've several hundred identities in
use, so as it stands the only way I'd have complete control is to define
several hundred accounts and match them all up.

At present I don't actually define a default identity for any of the
outbound SMTP accounts I have.   

Also I keep all the send accounts disabled so I won't accidentally click on
one in a transfer menu etc, and only the sole enabled one has "Make this
your default send account" ticked.  

I do have an identity labelled as the default in the list of all identities,
but have a filter defined which traps anything I attempt to send using that
identity, since normally I'd want to use a destination-specific identity for
any particular mail.  

I also have some filters that sanity check identities also to make sure
that, for example, mails to mail list servers leave here with a jn.ml.
address, and so on.   

That's mainly because I've found out the hard way that the value in a
write-window's From: field can be inadvertently changed if I happen to roll
the mouse wheel while the mouse pointer is over that field.  I don't have to
have clicked on the From: field first for that to happen.  Every so often it
does when I was meaning to scroll the write window's text area, and it's
something I dislike because there's no warning that the value has been
changed. 

> - what's really needed is an option in the identity to point it toward a
> particular account rather than the other way around.

Yes, for the problem I thought I saw looming.   People "working from home"
may need this though, if - say - they are required to send work emails
through a specific corporate server.


>>   b) prevent forever any of us using differing SMTP servers as fallback
>>      in case our main / chosen server is not available
>
> For anybody using a domain that has such a restrictive policy in place,
> sadly this will be the case, but it shouldn't affect people who register
> their own domains unless they explicitly implement their own policy.

Phew!

-- 
Jeremy C B Nicoll - my opinions are my own.

______________________________________________________________________
This message was sent via the gemini-users mailing list
To unsubscribe, mail gemini-users+unsubscribe@...